Archive for the ‘Windows’ Category

What’s that IIS Process ID again?

Sunday, August 18th, 2013

First off, I’ll admit that it has been some time since my last post. I’ve moved into a new role at work that has much less emphasis on day-to-day development. However, I’ll still plan on posting interesting tidbits from time to time as I encounter them – just as I always have!

This one came up during a recent sprint of coding in which I was debugging a SharePoint 2013 farm solution (I know – apps are the way to go now!) with Visual Studio 2012. Let me say, since first starting development in MOSS 2007, this is a totally different and much smoother experience. I switched back-and-forth between using Visual Studio’s “Play” button – also known as “Start Debugging” – and a more traditional Build, Deploy, Attach to Process method.

When looking to attach to IIS, it’s always a gamble as to which w3wp.exe process to attach. However, this can be avoid by using the appcmd.exe utility. There is a nifty set of parameters that will allow you to view the currently running w3wp processes, their process IDs, and the names of the associated application pools. It’s just the right amount of information.

Enjoy and happy debugging!

Extracting Zip Files using PowerShell

Tuesday, July 17th, 2012

To help troubleshoot some SharePoint issues, I had a need to analyze some log files that were contained in multiple zip files; one log file per zip file. Since there were several hundred zip files to extract, I figured PowerShell could help! There are several posts I found with example scripts for how to perform this operation. I took pieces from many posts, added some COM object clean-up code, and wrapped this in a function. I hope it helps you in your scripting activities!

The code below is the function I’m using to extract a single zip file. It leverages the Windows Shell COM object (i.e. Windows Explorer) to extract the files by exploiting the fact that Windows Explorer treats zip files as folders. Therefore, the operation can leverage existing file copy methods between two folders.

Stuck Keys?

Thursday, March 8th, 2012

I was in the middle of a SharePoint demo this morning, was typing some input, and all of the sudden my development server was going crazy! It turns out to be a problem I’ve encountered many times before. The “e” key started Windows Explorer. The “r” key started the Run dialog. The list goes on. It’s so frustrating!

The first thing to check is StickyKeys, but being in the midst of a demo and quite certain I was not fiddling with my Shift key, I knew that wasn’t the culprit this time.

I researched a bit and found two potential solutions:

  1. CTRL + ALT + SHIFT + F12
  2. CTRL + SHIFT + Windows Key

The second solution worked for me and cleared up the issue immediately! Hopefully this little tidbit will help someone else; perhaps myself at a later date!

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.

Moving an Event Source to a Different Windows Event Log

Wednesday, August 3rd, 2011

It is typically best practice when developing .NET applications, including SharePoint customizations, to create an event source for Windows Event Logging while installing the application. Each event source on a Windows computer is tied to a specific log upon registration. I recently provided guidance on how to move an event source to use its own brand new event log. The following lines of PowerShell can do this quickly. Unless your .NET application has the event log hardcoded into itself, which it shouldn’t because the event source should be registered to a log during installation, then the move shouldn’t require any code changes.

I found that I had to reboot the machine after executing the above lines of PowerShell for this change to fully take effect.

Update – I also have had the need to update the event log properties. To do so, use the Limit-EventLog cmdlet. The following code limits the MyNewOrExistingWindowsEventLog event log to a size of 20 MB (20*1024*1024 or 20,971,520 bytes) and tells Windows to overwrite old entries with new entries as needed.