Seems like a few bugs exist in the PowerShell Web Administration cmdlets, for example I was trying to use Get-Website to find a website by its name but it always retured an array of all websites and ignored the name argument:

This DOESN'T WORK:

 $site = Get-Website -Name "DanSite"  

This WORKS:

 $site = Get-Item "iis:sites/DanSite"  

MSDeploy is really good for deploying websites and syncing up websites but it can be a real pain to configure and get going intially.  The MSDeploy documentation is a bit poor as well and quite often you'll get a very strange error which can be quite cryptic.  Here's a good example that had me stumped for a little while:

Info: Using ID '0204878c-dbb9-4ac8-8d38-1ed9f6f91e0b' for connections to the remote server. Error Code: ERROR_DESTINATION_NOT_REACHABLE More Information: Could not connect to the destination computer ("X.X.X.X"). On the destination computer, make sure that Web Deploy is installed and that the required process ("The Web Management Service") is started.
Error: The remote server returned an error: (404) Not Found.
Error count: 1.

The error message isn't actually too bad in this case, it's saying either the Web Management Service isn't running OR it can't find MSDeploy.  Ok so checklist for this problem:

- Web Management Service (WMSVC) is running on the target server
- Port 8172 is open (checked with Telnet for good measure)
- I can connect to https://servername:8172/msdeploy.axd
- MSDeploy is installed (c:\program files\IIS\MSDeploy\Microsoft Web Deploy V2\msdeploy.exe)

After running through all of this I still received the ERROR_DESTINATION_NOT_REACHABLE message.  So after a while of head scratching I looked at the msdeploy version numbers and noticed that my package was created on the build server using msdeploy version 7.1.1046.1 but on the target servers it was runing the latest version of MSDeploy which at the time of writing is 7.1.1070.1.  Something suspicious perhaps!!  

The Fix

I installed MSDeploy version 7.1.1046.1 on the target servers and bingo no more nasty error messages!  I don't know if this is just a coincidence and I will try and test by upgrading the build server version to the latest MSDepply version but for now this fixed the issue.

Recently I started to experient with creating my own network of sites with different class C IP addresses, there's quite a few companies offering SEO hosting with multiple class C IP addresses which is very useful and there are some reasonable prices around (beware you do get what you pay for though).  I have a mixture of WordPress and .net websites so I wanted an SEO hosting company that could cater for both as it seems most SEO hosting companies only offer Linux.

I came across 2gbhosting.com which on the face of it sounded quite good:

- 99.9% uptime guaranteed
- 24/7 support
- .net, php 5 and everything else you would pretty much need

I signed up with my 6 domains and I must say that I have never used such an APPALING service, the uptime is more like 50% (if you are lucky), the performance on a site with hardly any traffic is dog slow.  In fact one of my good ranking domains has now got the following description in Google:

Here's some reponses from their support after I logged several calls regarding the availability of my sites:

So if a backup is running I can tell you for a fact  that your sites WILL stop running, what a great service.  In summary DO NOT USE 2GBHOSTING.COM FOR YOUR SEO HOSTING.

Had a good one recently on a newly built server whilst trying to get PowerShell WinRM working with a local admin user, here's the scenerio:

 Enter-PSSession -ComputerName servername -Port 81 -cred servername\localusername  
 [servername]: Import-Module webadministration   

Process should have elevated status to access IIS configuration data.

When running this as a local admin account I receive the error "Process should have elevated status to access IIS configuration data.", yet if I use my domain account which is also in the admin group on the server in question then everything works!  How weird...

Anyway the problem lies in the Remote User Account Control (UAC) settings in the registry, here's the fix (taken from http://support.microsoft.com/kb/942817):

1. Run regedit
2. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type LocalAccountTokenFilterPolicy for the name of the DWORD, and then press ENTER.
5. Right-click LocalAccountTokenFilterPolicy, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Exit Registry Editor.

or in Powershell:

new-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -Name "LocalAccountTokenFilterPolicy" -Value 1

This setting will take effect straight away so no reboot required.