Solarwinds AppInsight: Unable to create wsMan listener (Error code: 16024).

I was trying to get AppInsight IIS working on my SharePoint boxes. The automatic configuration option through SAM threw up this error:

Unable to create wsMan listener (Error code: 16024).

Upon checking the SPN on the SharePoint server I found that the http option were missing:

setspn -L Sharepoint01
Registered ServicePrincipalNames for CN=Sharepoint01,OU=Sharepoint 2010,OU=Serv

To fix this, you can add the spn by running the following command(s):



setspn -A HTTP/Sharepoint01 Sharepoint01

Registering ServicePrincipalNames for CN=Sharepoint01,OU=Sharepoint 2010,OU=Ser
Updated object

setspn -A HTTP/ Sharepoint01

Registering ServicePrincipalNames for CN=Sharepoint01,OU=Sharepoint 2010,OU=Ser
Updated object



Once this is done, go back to Solarwinds SAM and re-run the automatic configuration

If you host https, you will need to run the same commands replacing http with https.

get-wmiobject returns object not found

If you run get-wmiobject and it returns an error that says Object not found. Here’s how to fix it:


For Server 2003:
rundll32 wbemupgd, RepairWMISetup

For Server 2008:
winmgmt /verifyrepository

If this doesn’t work, try renaming or deleting the repository:

First, you need to stop the WIN Management service
net stop winmgmt

Then, rename the existing WMI repository directory

Finally, Start the WMI service.
net start winmgmt


Beyond that you can try re-registering all of the DLLs and executables in the Wbem directory.


Screenshot below:





IIS exploits in Windows Server and how you can fix them

This is a really good article from techtarget:


I believe it’s safe to say that a common goal of Windows server administrators is to have reasonably resilient systems. There’s a lot going on in the world of online security threats. The last thing you need is someone on the other side of the world, or internal to your organization, exploit something in IIS or Windows server that could’ve been prevented.

Your hands may be tied in terms of application-specific flaws but there’s plenty you can do at the server level to make your IIS-based systems more secure. In reviewing my Web security assessment projects over the past year, here are the top IIS vulnerabilities afflicting Windows servers:

Unhandled exceptions (HTTP 500 errors) are generated.
This can disclose sensitive configuration information and facilitate SQL injection. The server-side fix is to disable detailed error messages via the following in the server’s web.config file:

<customErrors mode=”RemoteOnly” defaultRedirect=”AppErrors.aspx”>

<error statusCode=”404″ redirect=”NoSuchPage.aspx”/>

<error statusCode=”403″ redirect=”NoAccessAllowed.aspx”/>

<error statusCode=”500″ redirect=”RequestNotAllowed.aspx”/>


Viewstate parameter encryption and MAC are disabled.
This can allow an attack to manipulate sensitive parameters and gain unauthorized access. The server-side fix is to enable viewstate hashing and MAC on all pages of the application via the following to the server’s web.config file:


<pages viewStateEncryptionMode=”Always”>

<pages enableViewStateMac=”true”/>

<machineKey validation=”3DES”/>


Unencrypted HTTP connections can be made.
This can lead to the exposure of login credentials and other sensitive information because everything to and from the Web server is transmitted plaintext communications. The server-side fix is to require TLS version 1.1+ encryption across the entire website/application.



Find more PRO+ content and other member only offers, here.

SSL versions 2 and 3 and weak encryption ciphers are enabled.
This can facilitate man-in-the-middle attacks and lead to the compromise of sensitive information. The server-side fix is to require TLS version 1.1+ and disable weak ciphers such as RC4.

Cross-frame scripting is possible.
This can facilitate clickjacking and trick users into clicking on something different from what they perceive they are clicking on. The server-side fix is to set the X-Frame-Options header to DENY, SAMEORIGIN or ALLOW-FROM based on your specific needs.

Sensitive server directories and files are publicly-accessible.
This can expose system configuration, code or sensitive data. The server-side fix is to ensure that only the necessary permissions are enabled for public access.

Windows patches are missing.
This can lead to anything from denial of service to full remote access to the Web server using a tool such as Metasploit. The server-side fix is to patch your servers. It’s that simple. Even if you’re concerned about taking production servers offline, patching needs to be performed consistently across the board if you’re going to have a secure Web environment.

Most of these vulnerabilities may not be considered “critical” but they can certainly be problematic long term. As you can see, they’re relatively easily to resolve. In fact, the only thing it will cost you to fix them is your time. Find and fix these issues — they’re easy security wins for your business and will help keep your vulnerability scan and security assessment reports as clean as possible.

Once you tackle these website security server fundamentals you can more on to bigger — often more complex — security flaws within your Web applications themselves. This includes everything from cross-site scripting (an all too common vulnerability) to SQL injection (a less common yet lethal flaw) to weak user authentication and session management. That’s where the real fun begins.

Converting NDRs to x500


You ran a script to modify SMTP addresses on an Exchange 2010 user and accidentally overwrote all of their previous SMTP addresses including the legacyexchangeDN aka x500. (or you accidentally deleted a user and created their mailbox to the same AD account)

Now internal users are reporting that they’re receiving NDRs about the user no longer exists, even though you’ve already added the same exact SMTP address to their mailbox

Cause: Internal users typically caches the x500 address for internal communication instead of using SMTP addresses.


Not so efficient solution: Have every users that have this person’s contact autofilled in their Outlook client delete the contact from the autofill and re-enter their SMTP address.

Better: Have someone send a NDR to you for this particular user and recreate the x500 from that NDR on this user’s mailbox



Delivery has failed to these recipients or distribution lists:

Nguyen, Peter
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

If you click on the name, the NDR will get resolved to:

EXCH is the Exchange Organization name

So now we need to convert the above address into proper x500

First step: Replace all underscores “_” to “/”


Then replace all +28 to “(” and +29 to “)”

Replace all +20 to space ” ”

Replace all +2E to a period “.”

The final x500 would look like this:


Now just add this new string to the user’s Alias under the Exchange console as a custom address and you’re golden.