WMIPing Utility

I am working on a project that needs to connect to the SQL Server Reporting Services WMI Provider on remote machines.  I have had to work with a number of issues around security and needed a simple tool to help me diagnose them.  To that end I wrote a simple command line application in C# that allows me to pass in a target WMI Namespace as well as optional user name, password, and domain name values to test connectivity.  I thought some others might find it useful as well so I am posting it here.

You can download my WMIPing utility and the .NET (Visual Studio 2008) source code here.

If you are learning to use WMI from .NET, this may also server as a simple sample project.

Let me know if you use it, like it, hate it, want to change it, etc. However, I reserve no rights so feel free to change it on your own as you wish.

There is a readme included with the utility, but the usage is:

WMIPing <TargetNamespace> [<UserName>] [<DomainName>]

Where:
  <TargetNamespace> = The target WMI namespace to connect to.
                      For example:

                      "root\cimv2"

                      To ping a namespace on a
                      remote machine start the namespace with the target
                      machine name.  For example:

                      "\\<remotemachinename>\root\cimv2"

                      For a remote machine named "MyServer":

                      "\\MyServer\root\cimv2"

  [<UserName>]      = The optional user name to use when connecting remotely
                      You will be prompted for the password to use
  [<DomainName>]    = The domain to use when connecting remotely.
                      Requires <UserName>

FYI, If you are in the same boat as me and need to connect to a SQL Server Reporting Services instance, you can use this utility to test connectivity to the namespace.

WMIPing "\\<ServerName>\root\Microsoft\SqlServer\ReportServer\RS_<InstanceName>\v10" (assuming it is SQL 2008 or SQL 2008 R2)

In my dev environment, my reporting services server name is called “SQLVM” and I have a default instance (MSSQLSERVER) and named instance named “SQL2008”. 

Testing connectivity to the default instance (MSSQLSERVER) on the SQLVM server would look like:

WMIPing "\\SQLVM\root\Microsoft\SqlServer\ReportServer\RS_MSSQLSERVER\v10"

Connecting to the “SQL2008” named instance would look like:

WMIPing "\\SQLVM\root\Microsoft\SqlServer\ReportServer\RS_SQL2008\v10"

etc.

The WMIPing utility doesn’t do anything other than test that you can successfully connect from your client machine to the desired WMI namespace on the target server.

Creating Service Principal Names (SPNs)

Through the years I have had to create a Service Principal Names on servers in Active Directory for one reason or another. So far in the past, I have always used the SETSPN.EXE utility from the support tools that ships with Windows to create thos SPNs. SETSPN however was never that friendly of a tool to me.

Today, I discovered through a few locations on the net that you could also use ADSIEDIT.MSC (also ships in the support tools with Windows) to manage SPNs. Cool. Basically once you have installed the support tools you can run ADSIEDIT.MSC.

From within there, navigate through the tree to the computer or user account you are trying to edit SPNs for. Right click on the CN=… entry for the item and select “properites”. On the “Attribute Editor” tab double click on the “servicePrincipalName” attribute to manage the SPNs for that object. Pretty handy, and more intuitive than the SETSPN.EXE command line.

Shadowing Console Sessions with Remote Desktop

I use remote desktop all the time to connect to servers. One of my favorite features that I discovered some months back was the ability to connect directly to the console session of a server by using the mstsc … /console command line switch or the “connect to console:i:1″ entry in an rdp file. This is great when you need to connect to the console of the server to access programs that are running there. However, there can still be only a single person logged into a console at a time so when you connect remotely, you kick of anybody that might have been currently signed in there.

Today when I was bouncing around the net, I found another cool feature that allows you to shadow another session. I am sure all of this is old news to Citrix or App mode Terminal Services admins, but my limited experience with Terminal Services in the past makes this a gem of a discovery.

Basically shadowing a session allows you to watch via remote desktop what the user of the session is doing. You can shadow the console session itself by using the “shadow 0″ (that is a zero) command line in another remote session.

Microsoft has a KB article that describes how to do all of this at:
http://support.microsoft.com/kb/278845

Cool stuff!