Hot on the heels of my previous post, New-SPProfileServiceApplication -SiteNamingConflictResolution documentation bug, the -MySiteManagedPath parameter also has inconsistent documentation with the actual cmdlet in the wild.
[Note for reference this applies at the time of this writing to SharePoint Server 2013 with the March 2013 PU + December 2013 CU, farm buildversion 15.0.4551.1508]
TechNet defines the MySiteManagedPath parameter like this:
Parameter Required Type Description MySiteManagedPath Optional System.String Specifies the managed path where personal sites will be created.The type must be a valid URL, in the form http://server_name.
And Get-Help New-SPProfileServiceApplication -Full like so:
-MySiteManagedPath <SPPrefixPipeBind>
Specifies the managed path where personal sites will be created.
The type must be a valid URL, in the form http://server_name.
Required? false
Position? Named
Default value
Accept pipeline input? True
Accept wildcard characters? false
Both documentation references say you need to provide a valid URL. Of course, you’re providing a managed path so a better example would be something like “http://server_name/managedpath”.
When you specify a URL the cmdlet will throw a Microsoft.SharePoint.PowerShell.SPCmdletPipeBindException with the message:
Cannot find an SPPrefix object with Name: http://server_name/managedpath
What the cmdlet really wants is the actual name of the managed path. The cmdlet runs as expected when you give it a managed path name (that exists!) instead of a URL.
For example, say you have a My Sites web application http://mysites and you’ve created a Wildcard Inclusion managed path called “personal”.
The documentation says to do this (incorrect):
New-SPProfileServiceApplication ... -MySiteManagedPath "http://mysites/personal"
Instead give it the name of the managed path like this (correct):
New-SPProfileServiceApplication ... -MySiteManagedPath "personal"