Archive for February, 2012

SharePoint Diagnostic Studio Logon Failure

Monday, February 6th, 2012

I was introduced to the SharePoint Diagnostic Studio 2010 at the Microsoft SharePoint Conference 2011 in Anaheim, CA. I was very excited about its capabilities and have just gotten around to testing it in the last couple of days.

After configuring PowerShell remoting between my laptop and my development server, I set out to create a new project in the SharePoint Diagnostic Studio and see what it could do. Upon creating a new project, I entered my credentials. After a few moments, I received the following message.

It appears the new project installation was not successful. Click OK to see the error message

After clicking OK, the error log is opened. If it does not open for you, my log was at %HOMEPATH%\Documents\SharePoint Diagnostic Studio\Server Extensions\Error.log In the error log, I saw the following message.

Logon failure: unknown user name or bad password.

After getting quite paranoid about being up early in the morning with my two-month old and perhaps not remembering any of my passwords, I started to investigate things on the server to see if I could figure out what was going on. What I found has to do with my configuration of CredSSP authentication.

With CredSSP authentication, there are two preferred/secure ways of submitting credentials: Kerberos authentication and Certificates. These required extra configuration of PowerShell remoting that I haven’t quite gotten to just yet. Therefore, my remoting capability was relying on the third and less secure way of submitting credentials: NTLM.

It turns out, after investigating my server’s security log, the SharePoint Diagnostic Studio (or perhaps the underlying PowerShell commands) are attempting to first authenticate using Kerberos. That fails and I would expect that since I didn’t do all of the necessary configuration for Kerberos to work. However, it then falls back to NTLM. To my surprise it does not use the credentials I had specified. Rather, it was using my local laptop credentials!

To trick any application in to sending other credentials when it wants to send the credentials of the currently logged in user, you can use the Runas command which allows one to execute any program under another user. For this instance, SharePoint Diagnostic Studio shouldn’t run under the remote account. It should run under the local account, but use the remote account for any remote access. Thankfully, Runas has just such a provision – its /netonly switch! The following command will open SharePoint Diagnostic Studio under the local account while using the remote account to access the remote server.

runas /netonly /user:DOMAIN\USERNAME "C:\Program Files\Microsoft\SharePoint 2010 Administration Toolkit\SPDIAG.EXE"
(The Runas command will ask for a password before launching SharePoint Diagnostic Studio.)

Have fun!

Access Denied when Enabling PowerShell Remoting

Thursday, February 2nd, 2012

Quick tip: Are you receiving Access Denied messages when you are attempting to run the Enable-PSRemoting cmdlet? I’ve received them on machines connected to a domain, even when I’m running in an elevated PowerShell window. An easy trick is to open a PowerShell window as the built-in administration account on the machine. Not sure why, but for whatever reason, it seems to work!

VirtualBox Unidentified Network

Thursday, February 2nd, 2012

Thanks to Oisin Grehan and his Nivot Ink blog for providing the foundation of this post!
VMWare VMNET Adapters Triggering Public Profile for Windows Firewall

I use Oracle’s VirtualBox to run x64 SharePoint virtual machines from my laptop. I’ve also noticed an Unidentified Network in my Windows 7 list of networks. That is caused by VirtualBox’s Host-Only Network Adapter. It wasn’t harming anything at the time so I left it alone.

However, I later attempt to enable PowerShell remoting on my host laptop for work with SharePoint scripting. Upon doing so, I was greeted with the following error message while attempting the Enable-PSRemoting cmdlet:

Set-WSManQuickConfig : WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.

Another helpful error message! That seems easy enough; Windows makes it very easy to modify the settings for each individual network adapter to Private, Work, or Public depending on your personal preference. However, this is not the case with an unidentified network. With an unidentified network, Windows sticks to its Public settings and will not change it.

So can I now not enable PowerShell remoting since I can’t remove the Public designation of VirtualBox’s unidentified network? No! VirtualBox’s Host-Only network isn’t really a true network connection at all. It is an endpoint adapter. Kudos to Oisin Grehan for developing a nice PowerShell script that will solve the issue by telling Windows, via the registry, that the network adapter is an endpoint device and not a true external network connection. This will cause Windows to stop treating the VirtualBox Host-Only adapter as a network and thus remove the unidentified network (and its public designation) from my list of networks. Problem solved! I’ve modified Oisin’s script to account for VirtualBox’s Host-Only instead of VMware adapters.

Note: This script will need to be executed every time VirtualBox is updated because the update will replace the existing adapter and cause the settings in the registry to be lost.