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.

I'm currently looking at implenting sitesearch for one of my client sites, I looked at a few options including Microsoft's Search Server Express 2010 and a commercial solution from http://www.sitesearchasp.net.

Here's my results:

Microsoft Site Search Express 2010

In a nutshell I a spent about half a day trying to get this working, don't waste your time with this crap (being polite as possible) as it's an absolute nightmare.  It's quite a big install and it actually installs SharePoint 2010 as well which I didn't particually want.

See the following blog posts on the "hacks" required to get it working on a non domain server:
http://soerennielsen.wordpress.com/2010/07/15/how-to-install-a-sharepoint-2010-complete-server-without-ad/
http://www.trinkit.com/blog/2009/4/9/the-sharepoint-search-service-and-anonymous-access

After doing all of this I still couldn't get it working with a nice error from Sharepoint:

At this point with nothing sensible coming form the logs I lost the will to live, deleted everything and am currently trying to delete the thought of SharePoint  from my memory.  Lets move on....

SiteSearchAsp.Net

Report coming soon....

This might catch some people out:  Downloading a ps1 file from the Internet and tring to execute results in error:

Run only scripts that you trust. While scripts from the Internet can be useful, this script can potentially harm your computer. Do you want to run C:\Downloads\SetupEnterpriseSearch.ps1?

Even with executionpoilcy set to unrestricted you'll get this message, this is because by default these files downloaded are maked as blocked so to unlock simply right click on the script in question and click "unblock".

Whilst looking at implementing a site search feature for one of my client sites I thought I'd look at Microsoft's free Search Server 2010 Express to see if I can use it to crawl my MVC3 razor website that I'm working on.  

First of all I'd try to install Search Server 2010 but quite quickly found that if you don't have a domain account then you'll receive the following error:
"the account must be a valid domain account"

Thanks that's really useful!  I came across this excellent article which with a bit of PowerShell allows you to work around the problem by:

1.  After install cancel the SharePoint configuration wizard
2.  Drop down to the SharePoint Management Shell
3.  Run New-SPConfigurationDatabase
2.  Now you're good to go with the wizard by running PSConfigUI

Finally decided today that I no longer want to use the DOS command prompt, PowerShell is the way to go for everything!  But when I do use the VS DOS prompt it's normally because I want to use msbuild which means setting the correct envionment path.  A quick Google brings up some samples so I "lifted" one from here and changed it for VS 2010.

In PowerShell locate your profile:

  notepad $profile  (if you get prompted to create the file because you don't have a profile then click yes to create it)

Now here's the contents of Microsoft.PowerShell_profile.ps1:

 pushd 'C:\Program Files\Microsoft Visual Studio 10.0\vc'  
 cmd /c “vcvarsall.bat&set” |  
 foreach {  
  if ($_ -match “=”) {  
   $v = $_.split(“=”); set-item -force -path "ENV:\$($v[0])" -value "$($v[1])"  
  }  
 }  
 popd  
 write-host "`nVisual Studio 2010 PowerShell Prompt" -ForegroundColor Yellow  

Open up PowerShell and all of the VS commands are availble!...Good bye DOS!!

It's quite simple to find the name of the operating system with PowerShell.  The WMI cmdlet GetWmiObject contains a lot of useful information about the environment, there's numerous ways to use the object but here's one method:

 (Get-WmiObject Win32_OperatingSystem).name  

This should work straight away but for me I encounted some "weird" issues which suggested there were some problems with my Windows installation and specifically the WMI repository.  Intially I received the following error: running the above command:

 InvalidOperation: (:) [Get-WmiObject], COMException  

Here's what I did to fix the problem:

• Acertain if there is a problem with WMI (C:\Windows\System32\wbem)
  winmgmt /verifyrepository
• This this should show you if there are any issues with WMI, this came back and said everything was ok when clearly it wasn't!...
• I rebuilt the repository in PowerShell
  

   winmgmt /resetrepository  
   Restart-Service winmgmt -Force  

This can be useful if you're looking for blogs in a certain niche:

intitle:makeup intext:comment inurl:blog