Unable to find type [Parameter]: make sure that the assembly containing this type is loaded

Just learning about parameters in Powershell and came across this error:
Unable to find type [Parameter]: make sure that the assembly containing this type is loaded

Yes, I am running Powershell v2.0 and no I did not easily find any reference to this in my searches.

Through some trial and error, I figured out that in my Param() declaration, I had this:
Param(
...
,
[Parameter]
[String] $Description
,
...
)

The "[Parameter]" declaration was the culprit. My other ones had [Parameter(Mandatory=$true)]. So, I just removed the line and all works fine again.

Datasheet view is not supported on 64-bit versions of Office 2010

I just got a new laptop with a decent amount of memory. It also has a 64-bit version of Office 2010. I noticed that my SharePoint lists would no longer allow me to view in Datasheet view with the following error returned:
The list cannot be displayed in Datasheet view for one or more of the following reasons:
A datasheet component compatible with Microsoft SharePoint Foundation is not installed.
Your web browser does not support ActiveX controls.
A component is not properly configured for 32-bit or 64-bit support

Doing some further research I came across this:

You cannot view a list in Datasheet view after you install the 64-bit version of Office 2010

The best part is: If your business needs do not require you to use the 64-bit version of Office 2010, we recommend that you uninstall the 64-bit version of Office 2010 and install the 32-bit version of Office 2010. A 32-bit version of the Datasheet component is installed with the 32-bit version of Office 2010.

There is a workaround which is to install 2007 Office System Driver: Data Connectivity Components

However, that has implications such as needing to uninstall and reinstall this should you need to add more components to Office 2010. That sounds like a disaster waiting to happen.

Seriously!?

Remove site groups

I regularly create webs and subwebs with non-inherited permissions. This results in a bunch of permissions groups created for those webs. For some reason, deleting the web does not remove the corresponding groups. Since sometimes there are a lot, I decided to write a script to do this:

$web = Get-SPWeb <URL of root web>
$groupstodelete = $web.SiteGroups | Where-Object {$_.Name -eq "<whatever matching criteria>"}
$groupstodelete | ForEach-Object {$web.SiteGroups.Remove($_.Name)}

Simple and saves me a lot of clicking

Compiling all audiences

I have a Powershell script that adds users and wanted it to also compile audiences. I thought this would have been under on of the UserProfileManager or the UserProfileConfigManager classes. However, it appears that it is only available under the RunAudienceJob static member of the Microsoft.Office.Server.Audience class. Fortunately, it is fairly straightforward to execute:

$applicationId = (Get-SPServiceApplication -Name 'User Profile Service Application').Id

$AUDIENCEJOB_START = '1'  

$AUDIENCEJOB_INCREMENTAL = '0'  

[Microsoft.Office.Server.Audience.AudienceJob]::RunAudienceJob(@($applicationId, $AUDIENCEJOB_START, $AUDIENCEJOB_INCREMENTAL))

... with some inspiration from: SharePoint 2010 Compile All Audiences 

Automatically creating My Site personal site

A user's My Site personal site is automatically created the first time they click on the My Content link. However, for other reasons, I need to have these personal sites already created before they log in. As a result I went looking for a script to do this.

Here is essentially what I tried:

$URL = "http://someurl"     
$accountName = "myuser"

$site = New-Object Microsoft.SharePoint.SPSite($URL) 
$context = [Microsoft.Office.Server.ServerContext]::GetContext($site) 
$upm = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context) 

$userprofile = $upm.GetUserProfile($accountName)
$userprofile.CreatePersonalSite();

This was not successful in creating the personal site.

The account under which I run this has administrator rights on the User Profile Service Application, and is in the Farm Administrators Group. In the ULS there was an entry for "Access Denied". I also do have Self Service Site Creation enabled.

Seeing as this was an "Access Denied" I then tried to run the script as the SharePoint Farm Account. This was successful. Unfortunately, I do not want to run this script as the Farm Account.

Next step was to try running this with elevated privileges which involved putting my code within this:

[Microsoft.SharePoint.SPSecurity]::RunWithElevatedPrivileges()

Still no luck

Next was to try using a different user token like this:

$site = New-Object Microsoft.SharePoint.SPSite("myurl", [Microsoft.SharePoint.SPUserToken]::SystemAccount)

or even with the user account for which I am creating the personal site.

Still no luck.

At this point, I gave up and put my script into the Task Scheduler to be executed as the Farm Account.

It would be nice to know exactly what permission is missing.

Amazon EC2 Powershell

I keep forgetting where to find the latest and somehow never use the right search terms. So, here is the location of the Amazon EC2 API Tools which include the Powershell cmdlets
http://aws.amazon.com/developertools/351

And for completeness, the AWS toolkit is here: http://aws.amazon.com/sdkfornet/

And now for Windows is here: http://aws.amazon.com/powershell/

My Site creation failure ... System.ArgumentException: Another site already exists ...

My users were going to their My Content area for the first time (ie: creating their personal site) and got the following error:
There has been an error creating the personal site. Contact your site administrator for more information
Checking the ULS, I see the following:

My Site creation failure for user '[some-user]' for site url '[some-site]'. The exception was: Microsoft.Office.Server.UserProfiles.PersonalSiteCreateException: A failure was encountered while attempting to create the site. ---> System.ArgumentException: Another site already exists at [some-site]. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.    


It turned out that my Personal Site Location had been changed from "my/personal" to just "my" so it was not pointing at a wildcard inclusion managed path.