Month: March 2011

So, after you’ve set up your farm (Or even if you’ve only just upgraded or added a new WFE to the farm) it’s always interesting to see what Microsoft’s Health Analyzer has to say about the new configuration. Now, we could just sit around and wait for each job to fire off thanks to the SharePoint Timer at various intervals and check periodically as the alerts are triggered, however, I’m more the kind of person who likes to get the bad news all at once. This ends up giving me a nice little checklist of “Things I Need to Fix” for the day (ok, sometimes it takes more than a day). Enter the power of PowerShell. Using PS, we can look for a list of all SPTimerJobs that have the word “Health” in them, and pass that list of SPTimerJobs into the Start-SPTimerJob commandlet, which will fire off all our Health Analyzer checks in a relatively short time. Here’s the code for PS: #First load the SharePoint commands if not using the SharePoint PS Shell Add-PSSnapin "Microsoft.SharePoint.Powershell" #And now kick off all Health Timer Jobs Get-SPTimerJob | Where {$_.Name -like "*Health*" -and $_.Name -like "*-all-*"} |...

I was playing with some PowerShell and wanted to use the Out-Gridview command that is part of CTP 2.0, but when trying to us it in my script I kept getting an error message that it wasn’t supported. This command sends output to an interactive table in a separate window, a very useful function when dealing with large amounts of data that looks pretty nasty in a text only environment. As it turns out, many of the product PowerShell hosts that are shipped are in fact minishells (such as the SQLPS shell) and not all commandlets are available including the OGV as you might expect in a normal PowerShell console. Rule of thumb here is always use the Powershell windows and just use initialization scripts for the functions you want. I generally get away from having to deal with minishell issues by always running the main PS shell and including this line in my \My Documents\WindowsPowershell\Profile.ps1 file, which autoloads the registered snap-ins of the computer I happen to open my PowerShell in: get-pssnapin -registered | add-pssnapin...

Another soapbox post… Seriously, if you’re hiring a consulting company or going offshore, don’t just trust that they know how to develop SharePoint solutions that are portable and don’t suck. What do I mean by that? Last month we had some code delivered from offshore. We did not specify that they should follow good SharePoint coding standards, so what we got was a system that worked, but was as about as far removed from what makes a good SharePoint solution as possible. Things to tell the next development team should include: Do not update the out of box default master page through SharePoint designer. For that matter, never update the default master page. never never never. You should always leave the out of box stuff alone. This also means no overwriting of OOB SharePoint files in the hive. If you must deploy to the hive, always use a sub-directory, never write to the root of the hive. Forget about .stp files. For development deliverables they don’t exist and should never be in a deliverable. Always set up site and list definitions in code. Any piece of code must always be delivered packaged in a .wsp, having a folder in the deliverables with an implementation note about where to copy the contents on the server? NO! Makes it a nightmare when you try to join another server to the farm....