I was on site with a customer last week and was tasked with tidying up their infrastrucutre build scripts which were written in Powershell. The scripts themselves are pretty awesome, and if you are looking at doing this yourself, grab the AutoSPInstaller scripts from CodePlex: http://autospinstaller.codeplex.com/
One of the issues with the scripts as they were, was that when trying to add custom user profile properties (at the point where we would try to get the UserProfileManager), we got the nice indicative error: "No User Profile Application available to service the request. Contact your farm administrator." After a quick search, I came up with this post by Steve Peschka that hit the nail on the head: http://blogs.technet.com/b/speschka/archive/2010/02/22/no-user-profile-application-available-mystery-in-sharepoint-2010.aspx Basically, the account the script is running as needs to be added to the Service Application's Administrators permssion, and also granted the Full Control permission under Permissions. (Yes, both locations)
My next question was: "Great! How do I do this in Powershell?"
More not-quite-so-quick searching revealed some code written by Charlie Holland: http://www.chaholl.com/archive/2011/02/10/programmatically-configure-service-application-permissions-in-sharepoint-2010.aspx He had coded up an example in C#, but it was up to me to turn this into Powershell, which wasn't easy for me, so I decided to share the code for this wherever I can, including this blog. :)
$UserProfileApp = Get-SPServiceApplication -Name "User Profile Service" New-SPProfileServiceApplicationProxy -Name "User Profile Service Proxy" -ServiceApplication $UserProfileApp -DefaultProxyGroup ## Set permissions to the User Profile Application so that we can add user properties to it later... [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") $spFarm = [Microsoft.SharePoint.Administration.SPFarm]::Local $mgr = [Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager]::Local $claim = $mgr.ConvertIdentifierToClaim($config.Farm.RemoteConnection.Username, [Microsoft.SharePoint.Administration.Claims.SPIdentifierTypes]::WindowsSamAccountName) $spAclAccessRule = [Microsoft.SharePoint.Administration.AccessControl.SPAclAccessRule``1] $security = $UserProfileApp.GetAccessControl() $spIisWebAppRights = [Microsoft.SharePoint.Administration.AccessControl.SPIisWebServiceApplicationRights] $aclAccessRule = $spAclAccessRule.MakeGenericType($spIisWebAppRights) $actualAccessRule = New-Object($AclAccessRule) $claim, "FullControl" $security.AddAccessRule($actualAccessRule) $UserProfileApp.SetAccessControl($security) $security = $UserProfileApp.GetAdministrationAccessControl() $spCentralAdminRights = [Microsoft.SharePoint.Administration.AccessControl.SPCentralAdministrationRights] $aclAccessRule = $spAclAccessRule.MakeGenericType($spCentralAdminRights) $actualAccessRule = New-Object($AclAccessRule) $claim, "FullControl" $security.AddAccessRule($actualAccessRule) $UserProfileApp.SetAdministrationAccessControl($security) $UserProfileApp.Uncache()
- Brendan Law
Just got the upa provisioning fully automated using powershell and psake, now to configure. This should help as the setup account didn't get access during he provisioning process as it had to be done by the farm service account. Is this made better in 2013?