SharePoint Automation Gary Lapointe – Founding Partner, Aptillon, Inc.

4Oct/1033

Service Accounts and Managed Service Accounts in SharePoint 2010

With SharePoint 2010 we now have the ability to allow SharePoint to manage various service accounts thus foregoing the need to have IT administrators manually manage password changes. This new feature is a great benefit to SharePoint administrators and security conscious admins in general as it allows us to easily enforce our corporate security policies by changing these passwords on a schedule, and the administrators don’t even know what the password is so the likelihood of a compromise due to a disgruntled admin, though not eliminated, is somewhat reduced.

But the introduction of this new feature isn’t all good. The complication comes from the fact that SharePoint 2010 doesn’t implement this capability consistently. So an account that is configured as a Managed Service Account and set to have its password changed automatically could also be used in certain places that don’t understand the managed account concept. When the managed account password is changed the feature that uses that account and only knows the username and password (so it does not use the managed account details) will effectively be broken. As an example, if you configure the Enterprise Search Service to use a managed account whose password is scheduled to be changed every 30 days and you use that same account for the content crawl account then when that password is changed the content crawl will cease to function as it will be unable to authenticate the account. It’s important to note, however, that this issue only comes to light when you configure the managed account to have it’s password changed automatically.

So what things can be managed accounts and what cannot? The following lists what I’ve come across so far (if I’ve missed anything please leave a comment so I can update these lists):

Managed Service Accounts:

  • All Service Application Pool Accounts
    • Access Service Application
    • BCS Service Application
    • Excel Services Service Application
    • Metadata Service Application
    • PerformancePoint Service Application
    • Enterprise Search Service Application
    • Secure Store Service Application
    • Subscription Settings Service Application
    • User Profile Service Application
    • Visio Services Service Application
    • Web Analytics Service Application
    • Word Automation Service Application
    • Word Viewing Service Application
    • PowerPoint Viewing Service Application
    • Security Token Service Application
  • All Content Web Application Pools
  • Service Instances
    • Claims to Windows Token Service
    • Document Conversion Launcher Service
    • Document Conversion Load Balancer Service
    • Microsoft SharePoint Foundation Sandboxed Code Service
    • SharePoint Foundation Help Search
    • SharePoint Server Search (Enterprise Search)
    • Web Analytics Data Processing Service

Service Accounts (should not be managed):

  • Search Crawl Accounts
    • For Foundation Search and Server (Enterprise) Search
  • Unattended User Accounts
    • Excel Services Service Application
    • Visio Services Service Application
    • PerformancePoint Service Application
    • (in general, any Secure Store application credentials)
  • Object Cache Portal Accounts
    • Super User Account
    • Super Reader Account
  • User Profile
    • Synchronization Service Account (listed incorrectly on the FarmCredentialManagement.aspx page)
    • Synchronization Connection Account
  • Server Search Custom Crawl Rule Accounts
    • Any crawl rule that specifies an account other than the default crawl account

Again, these are just the accounts that I’ve personally bumped up against so it may not be a complete listing.

Viewing and Creating Managed Accounts

To see the current list of Managed Service Accounts using Central Admin go to Security –> Configure managed accounts:

Configure Managed Accounts

You can edit the settings for any managed account by simply clicking the edit icon associated with the account you wish to modify. Once on the Manage Account screen you can configure the automatic password change settings:

Configure Managed Account

To perform the same tasks using Windows PowerShell we can use the Get-SPManagedAccount cmdlet to retrieve the list of managed accounts:

Get-SPManagedAccount

Or we can retrieve a specific account using the -Identity parameter or by passing in a Web Application or Service:

Get-SPManagedAccount -Identity "localdev\spfarm"

clTo change the settings for a Managed Account we can use the Set-SPManagedAccount cmdlet:

Set-SPManagedAccount

To create a new Managed Account we use the New-SPManagedAccount cmdlet. In the example below I’m manually creating a PSCredential object so that I can specify my password (pa$$w0rd) in script (very useful for building out dev or test environments – otherwise you should use Get-Credential to prompt for the password so that it is not hard coded anywhere):

New-SPManagedAccount

Applying Managed Accounts

Once you have your Managed Accounts created you can begin to use them for things such as Service Instances and Service and Content Application Pools. To associate a managed account with a specific Service Instance using Central Admin you can go to Security –> Configure service accounts. On the Service Accounts page you can set the account used for the Farm Account, Service Instances, Web Content Application Pools, and Service Application Pools. The Service Instances are highlighted in the following image:

Configure Service Accounts

Service Instances

To set the account associated with a particular Service Instance using Windows PowerShell we simply get the ProcessIdentity property of the Service Instance and set its Username property. Once set we call Update() to update the Configuration Database and then Deploy() to push the change out to all Service Instances. To make this easier I put this code in a function that I can call by passing in the Service Instance and credentials to use:

function Set-ServiceIdentity($svc, $username)
{
  
$pi = $svc.Service.ProcessIdentity
  
if ($pi.Username-ne $username) {
      
$pi.Username= $username
      
$pi.Update()
      
$pi.Deploy()
    }
}

Here’s an example of how you can call this function:

Set-ServiceIdentity

Service Application Pools

To create a new Service Application pool we use the New-SPServiceApplicationPool cmdlet and pass in the name of the Application Pool to create and the Managed Account to assign as the Application Pool identity:

New-SPServiceApplicationPool

It’s extremely important to note that the application pool that you create using the New-ServiceApplicationPool cmdlet cannot be used for your content Web Applications. Unfortunately there is no out-of-the-box equivalent for creating Application Pools for Web Applications.

Web Application Pools

As previously noted there is no cmdlet for creating Application Pools for Web Applications. Instead what you need to do is first check if the Application Pool you need already exists by using the SPWebService’s ContentService static property. If it exists then pass in just the name of the Application Pool to the New-SPWebApplication cmdlet, otherwise pass in the name and the Managed Account to use as the Application Pool’s identity:

New-SPWebApplication

Applying Service Accounts

When it comes to applying non-managed accounts to the various features things get a little more complicated. Let’s start with the Crawl Accounts.

SharePoint Foundation Search Service

For SharePoint Foundation Search we can set the crawl account (or content access account) using Central Admin by navigating to the Services on Server page and clicking the SharePoint Foundation [Help] Search link which takes you to the settings page where we can set the crawl account:

SharePoint Foundation Search Settings

To set the same information using Windows PowerShell we actually have to go old-school and use STSADM as there’s no PowerShell equivalent cmdlet. Here’s a snippet of PowerShell code that I use to accomplish this:

function ConvertTo-UnsecureString([System.Security.SecureString]$string)
{
    $unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToGlobalAllocUnicode($string)
    $unsecureString = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($unmanagedString)
    [System.Runtime.InteropServices.Marshal]::ZeroFreeGlobalAllocUnicode($unmanagedString)

    return $unsecureString
}

$searchSvcAccount = Get-Credential "localdev\spsearchsvc"
$crawlAccount = Get-Credential "localdev\spcrawl"

$stsadmArgs = "-o spsearch -action start " + `
    "-farmserviceaccount `"$($searchSvcAccount.Username)`" " + `
    "-farmservicepassword `"$(ConvertTo-UnsecureString $searchSvcAccount.Password)`" " + `
    "-farmcontentaccessaccount `"$($crawlAccount.Username)`" " + `
    "-farmcontentaccesspassword `"$(ConvertTo-UnsecureString $crawlAccount.Password)`" " + `
    "-databaseserver `"spsql1`" " +  `
    "-databasename `"SharePoint_FoundationSearch`""

Write-Host "Running: stsadm $stsadmArgs"
$stsadmoutput = cmd /c "stsadm $stsadmArgs" 2>&1
if ($lastexitcode -ne 0) {
    throw "Unable to start Foundation Search Service.`n$stsadmoutput"
}

Note that I’m using a helper function to convert the secure password to a static string which I can then pass to the STSADM spsearch command.

SharePoint Server Search Service

To manage the crawl account for the SharePoint Server Search Service (also known as the Enterprise Search Service) using Central Admin we simply need to navigate to the Search Administration page of the Service Application that we wish to modify and click the link for the Default content access account. This will bring up the following screen:

Default content access account

Note that by default this account will be set to be the same account you used for the Search Service Instance which is a Managed Account. If you do not change this account and you have configured SharePoint to manage the account password then your crawls will fail when the password changes. To make this change using Windows PowerShell we use the Set-SPEnterpriseSearchServiceApplication cmdlet:

$crawlAccount = Get-Credential "localdev\spcrawl"
$searchApp | Set-SPEnterpriseSearchServiceApplication -DefaultContentAccessAccountPassword $crawlAccount.Password -DefaultContentAccessAccountName $crawlAccount.Username

Remember not to do this step until after you have provisioned the Administration Component.

Object Cache Accounts

Many administrators when they first configure SharePoint 2010 and hit a Web Application for the first time are likely to see a recurring event in the event log stating that the object cache has not been configured correctly. The specific error is as follows:

Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.

This is essentially telling you that you have missed a manual configuration step in which you need to run some PowerShell to set two accounts for SharePoint to use to access the object cache:

function Set-WebAppUserPolicy($webApp, $userName, $userDisplayName, $perm) {
    [Microsoft.SharePoint.Administration.SPPolicyCollection]$policies = $webApp.Policies
    [Microsoft.SharePoint.Administration.SPPolicy]$policy = $policies.Add($userName, $userDisplayName)
    [Microsoft.SharePoint.Administration.SPPolicyRole]$policyRole = $webApp.PolicyRoles | where {$_.Name -eq $perm}
    if ($policyRole -ne $null) {
        $policy.PolicyRoleBindings.Add($policyRole)
    }
    $webApp.Update()
}
$webApp = Get-SPWebApplication "http://content"
$portalSuperUserAccount = Get-Credential "localdev\SPSuperUser"
$webApp.Properties["portalsuperuseraccount"] = $portalSuperUserAccount.UserName
Set-WebAppUserPolicy $webApp $portalSuperUserAccount.UserName $portalSuperUserAccount.UserName "Full Control"

$portalSuperReaderAccount = Get-Credential "localdev\SPSuperReader"
$webApp.Properties["portalsuperreaderaccount"] = $portalSuperReaderAccount.UserName
Set-WebAppUserPolicy $webApp $portalSuperReaderAccount.UserName $portalSuperReaderAccount.UserName "Full Read"

Make sure that you do not use the same account for both the super user and super reader. (And of course make sure you change the URL and account names to match your environment). For more information about these settings see the following TechNet article: http://technet.microsoft.com/en-us/library/ff758656.aspx

Unattended Accounts

There are some services, specifically the Visio Services Service Application, the Excel Services Service Application, and the PerformancePoint Service Application, that allow us to set an account that we can use for access data sources behind the scenes. These are called unattended access accounts. To set these accounts we must create a new target application in the Secure Store Service Application and associate the target application’s ID with the appropriate Service Application. The following PowerShell code demonstrates how to do this for the Visio Services Service Application (the Excel Services Service Application is virtually identical and just uses cmdlets specific to Excel rather than Visio; PerformancePoint is a lot simpler):

#Get the Visio Service App
$svcApp = Get-SPServiceApplication | where {$_.TypeName -like "*Visio*"}
#Get the existing unattended account app ID
$unattendedServiceAccountApplicationID = ($svcApp | Get-SPVisioExternalData).UnattendedServiceAccountApplicationID
#If the account isn't already set then set it
if ([string]::IsNullOrEmpty($unattendedServiceAccountApplicationID)) {
    #Get our credentials
    $unattendedAccount = Get-Credential "localdev\SPUnattended"

    #Set the Target App Name and create the Target App
    $name = "$($svcApp.ID)-VisioUnattendedAccount"
    Write-Host "Creating Secure Store Target Application $name..."
    $secureStoreTargetApp = New-SPSecureStoreTargetApplication -Name $name `
        -FriendlyName "Visio Services Unattended Account Target App" `
        -ApplicationType Group `
        -TimeoutInMinutes 3

    #Set the group claim and admin principals
    $groupClaim = New-SPClaimsPrincipal -Identity "nt authority\authenticated users" -IdentityType WindowsSamAccountName
    $adminPrincipal = New-SPClaimsPrincipal -Identity "$($env:userdomain)\$($env:username)" -IdentityType WindowsSamAccountName

    #Set the account fields
    $usernameField = New-SPSecureStoreApplicationField -Name "User Name" -Type WindowsUserName -Masked:$false
    $passwordField = New-SPSecureStoreApplicationField -Name "Password" -Type WindowsPassword -Masked:$false
    $fields = $usernameField, $passwordField

    #Set the field values
    $secureUserName = ConvertTo-SecureString $unattendedAccount.UserName -AsPlainText -Force
    $securePassword = $unattendedAccount.Password
    $credentialValues = $secureUserName, $securePassword

    #Get the service context
    $subId = [Microsoft.SharePoint.SPSiteSubscriptionIdentifier]::Default
    $context = [Microsoft.SharePoint.SPServiceContext]::GetContext($svcApp.ServiceApplicationProxyGroup, $subId)

    #Check to see if the Secure Store App already exists
    $secureStoreApp = Get-SPSecureStoreApplication -ServiceContext $context -Name $name -ErrorAction SilentlyContinue
    if ($secureStoreApp -eq $null) {
        #Doesn't exist so create.
        Write-Host "Creating Secure Store Application..."
        $secureStoreApp = New-SPSecureStoreApplication -ServiceContext $context `
            -TargetApplication $secureStoreTargetApp `
            -Administrator $adminPrincipal `
            -CredentialsOwnerGroup $groupClaim `
            -Fields $fields
    }
    #Update the field values
    Write-Host "Updating Secure Store Group Credential Mapping..."
    Update-SPSecureStoreGroupCredentialMapping -Identity $secureStoreApp -Values $credentialValues

    #Set the unattended service account application ID
    $svcApp | Set-SPVisioExternalData -UnattendedServiceAccountApplicationID $name
}

When it comes to PerformancePoint we have a lot less work we need to do as the product team was nice enough to make it so that the Set-SPPerformancePointSecureDataValues does all the work of setting up the target application for us (note though that they did screw up how the Service Application is passed into the cmdlet requiring you to pass in the ID of the Service Application rather than the actual Service Application object):

$unattendedAccount = Get-Credential "localdev\SPUnattended"
$secureValues = Get-SPPerformancePointSecureDataValues -ServiceApplication $svcApp.Id
if ($secureValues.DataSourceUnattendedServiceAccount -ne $unattendedServiceAccount.UserName) {
    Write-Host "Setting unattended service account $($unattendedServiceAccount.UserName)..."
    $svcApp.Id | Set-SPPerformancePointSecureDataValues -DataSourceUnattendedServiceAccount $unattendedServiceAccount
}

User Profile Synchronization Service Identity

One thing to watch out for is when setting the account for the User Profile Synchronization Service. This service wants you to use the Farm Account as the identity. This means that your Farm Admin account cannot have it’s password managed by SharePoint if you intend to use this service (or at least, it shouldn’t be unless you don’t mind manually fixing this service every time your password changes – good luck with that BTW). Your Farm Admin account will always be a Managed Account (you can’t change that) so be extra careful when changing this accounts password (either manually or automatically). To set this account using Central Admin you can click Start next to the User Profile Synchronization Service entry on the Services on Server page.

User Profile Synchronization Service

To accomplish the same thing using PowerShell we need to get an instance of the Synchronization Service and set a few properties and call the SetSynchronizationMachine method passing in the username and password of the Farm Admin account (note that it requires the password be passed in as a standard string and not a secure string so I use my previously defined ConvertTo-UnsecureString function):

$syncMachine = Get-SPServer "sp2010dev"
$profApp = Get-SPServiceApplication | where {$_.Name -eq "User Profile Service Application 1"}
$account = Get-Credential "localdev\spfarm"
if ($syncMachine.Address -eq $env:ComputerName) {
    $syncSvc = Get-SPServiceInstance -Server $env:ComputerName | where {$_.TypeName -eq "User Profile Synchronization Service"}
    $syncSvc.Status = [Microsoft.SharePoint.Administration.SPObjectStatus]::Provisioning
    $syncSvc.IsProvisioned = $false
    $syncSvc.UserProfileApplicationGuid = $profApp.Id
    $syncSvc.Update()
    $profApp.SetSynchronizationMachine($syncMachine.Address, $syncSvc.Id, $account.UserName, (ConvertTo-UnsecureString $account.Password))
}

if ($syncSvc.Status -ne "Online") {
    Write-Host "Starting User Profile Synchronization Service..."
    Start-SPServiceInstance $syncSvc
}
do {Start-Sleep 2} while ((Get-SPServiceInstance -Server $env:ComputerName | where {$_.TypeName -eq "User Profile Synchronization Service"}).Status -ne "Online")

Summary

As you can see setting the accounts that are used throughout SharePoint 2010 is anything but consistent and in some cases a real pain in the a$$. I know I didn’t cover how to set every account (custom crawl rule accounts, user profile sync connection accounts, others?) but hopefully someone out there has already documented these, or if not perhaps they’d be nice enough to post a comment here for others benefit from (maybe one day I’ll add them myself but for now I think this post is quite long enough). As always, please let me know if I’ve missed something or otherwise got something wrong as I certainly don’t claim to have all the answers.

Happy PowerShelling Smile

Comments (33) Trackbacks (6)
  1. Great post, Gary!

    Side Note: To make things potentially even more confusing, Windows Server 2008 R2 Active Directory Services includes a new container with the same name (Managed Service Accounts) and functionality (automatic password change) though the actual implementation is a bit different.

    This “Managed Service Accounts” AD container should definately NOT be used for service accounts you intend to use with SharePoint; accounts in this container can only be used on a single machine and SharePoint will not be notified that the password has been changed…

  2. Great Post!, Maybe you can help me with this problem:
    Today a customer told me that he changed the password of an account that was used to install and configure all the SharePoint 2010. IT is an small farm of a database and one front end server. I try to run script to update the current password but PowerShell told me that the I could not access the farm, and is true beacuse the password to access database change but how I can update it?.

  3. Desarrollo – you need to be logged in with an account that is a local admin on all the sp servers and has dbcreator and securityadmin on the sql box and also has db_owner rights to all databases. Then run the Set-SPManagedAccount cmdlet to reset the password of your farm admin account to the value set by your administrator (or just have your administrator change your password back). Note that you’ll also have issues with the user profile sync service and any other of non-managed services that I mention in this post if that account was used for any of them so you’ll need to address each of those

  4. Hello,

    really freat Post!
    But i have a little Problem with your function “Set-ServiceIdentity”.

    It don’t works for me to set my Account on “Claims to Windows Token Service”.

    No Output, I think everything was fine but when i look at Central Administration the User for the service is still “Local System”.

    Have you any ideas?

    • Three Service Instances are by default set up to run under the Local System or Local Service accounts: Claims to Windows Token Service, Document Conversions Launcher Service, and Document Conversions Load Balancer Service. In order to set the UserName to a Specific Managed Account, the “CurrentIdentityType” property of the ProcessIdentity must be set to “SpecificUser”. I modified Gary’s Set-ServiceIdentity function by adding a line above the username setter:


      if($pi.CurrentIdentityType -ne “SpecificUser”) {$pi.CurrentIdentityType = “SpecificUser”}
      $pi.Username= $username

      You can refer to this Thread for more info:
      http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/b0d3ddf3-c6bd-486f-847e-5697f46e26bd

  5. Hi,
    Nicely detailed post.
    2 Questions about the superuser and superreader accounts:
    are they just standard domain accounts or do we have to use the portal app pool account as super user and another account as super reader since they cannot be the same?
    Should we use different accounts for different web applications or can we use the same two accounts (in this case new account, no re-use of the portal app pool account) for all web applications of the farm. I suppose it all depends on the level of security we want to acheive !

    • You should not use the same account as your app pool as that account will have more rights than appropriate. Both accounts should be unique, but you can use them across web applications (I can’t think of any issues with doing that).

  6. Thanks, It’s a very helpful article..

  7. It’s very helpful post.
    I need some more info.
    What are the predeifned permissions for these managed accounts.
    I mean to say what permission we have define for this managed accounts on SQl & AD.
    Your reply would be much appriciated.
    Thanks,
    Hitesh

    • For most, nothing. Your setup account needs local admin on each sharepoint box and db_creator and security_admin on SQL but otherwise there’s no permissions to grant. That said, if you’re doing something like user profile sync then there will be extra permissions required; similarly if you are connecting to external datasources via Excel, Visio, BCS, etc. then you may need perms there.

  8. It is not clear why you write that some service accounts “should not be managed.”

    Are you saying that, when a managed service account password is automatically changes, those service settings are not updated and so will break the service?

    I am referring to the default content access account, for example.

    • That is correct. If SharePoint changes the password then the other services that don’t know about “managed settings” will break and you’ll have reset the password and any dependent services.

  9. If you use automatic password change in SP 2010:
    How can you retrieve the new password (set automatically)?
    How you may know what password has been set?

  10. Well detailed blog. Thank you for that.
    I have a client asking me how the password reset works in SharePoint. So basically they want to know what happens in the background? is it password set or reset? they were also wondering if the service which is managed by the managed account gets reset it every time there is a password reset.
    Thanks

    • If sharepoint is managing the password then it is simply setting a new, random password on the given schedule. I believe that services dependent on managed accounts whos passwords just changed will be restarted but I’ve honestly never looked to validate that.

  11. Thanks for the post Gary!

    I used this powershell method to change the Sandbox Service account. I have the Sandbox service running on 2 servers in my test farm. I ran the script from server1 for both Server1 and Server2. But looking in the “services” list on server2, the service account on server2 did not change. I confirmed the “$svc.Service.ProcessIdentity” does contain the new service account for that service on server2. I also verified that the domain account I’m logged into on server1 has local admin on both servers.

    Any idea what happened? What can I do to change the account for the sandbox service on server2 now that it’s not reflecting what is in the ConfigDB?

    Thanks!!

  12. Just confirmed it! When using powershell to change the service account, it seems to only change the service account on the node you run the powershell script from!

  13. Hi,
    First this post is awesome! I wonder why I didn’t find it before, it would have save me a lot of work!
    But I got 1 problem with the function Set-ServiceIdentity. When I do the $pi.Deploy() I get this error: Exception calling “Deploy” with “0″ argument(s): “Object reference not set to an instance of an object.”
    After double checking everything, I still can’t find any reason why it’s not working… The identity in SharePoint is changed when I look in Central Admin / Services Accounts which means the $pi.Update() worked fine. I just can’t get the Deploy() to work… My managed account is working fine, would I need to give it specific permissions?
    Thanks

    • Hard to say what the issue is without more information. After you get the error inspect the $Error variable to see the error details:

      $Error[0] | select *

      Post here and I’ll see if I can help further.

  14. Gary, I am somewhat confused over exactly what is managed and what is not. I noticed, for example, that the Excel Services Service Application is listed in both managed and unmanaged lists.

  15. Great detail, thx!

    Any idea which namespace I can use to view and manage service accounts in c#

  16. Hi Everyone,
    We are having a problem with SharePoint. We cannot publish an access database to SharePoint server 2010 as we get this error “An error occurred while initializing access services database.” whenever we try to publish the default contact database. By the way, we are using the single server environment (standalone). If you need more details just let me know. Any help would be appreciated guys, thanks.

    • Not all access databases are supported within SP. Check your ULS logs to see if there’s a more specific issue to help narrow down whether it’s a supportability issue or a configuration issue.

  17. Hi Gary,
    Thanks for your response. We are just publishing the default web contacts database template on Access 2010 and I am sure that this one is supported since I saw some videos and tutorials using this as an example for publishing Access db to SharePoint. Do you have an idea what causes this? Are we missing some configurations with the server to make these things work properly? Please advise, thank you.

    By the way, we checked our ULS logs as you said and we got a lot of things here that I can vaguely understand. Here are some events under access services category and under the Data Layer EventIDLevel.

    1. ResourceManager.PerformCleanup: Disk Manager: CurrentSize=0.11c5f189-4c41-07e6-0000-000

    2. ResourceManager.EvictUnusedItems: Disk Manager: Going to evict unused items. CurrentSize: 0. 11c5f189-4c41-
    3. ResourceManager.EvictUnusedItems: Disk Manager: After unused items eviction. CurrentSize: 0 Diff:0. 11c5f189
    4. ResourceManager.PerformCleanup: Memory Manager: CurrentSize=357650432.53fed7f1-4c41-07e6-0000-000

  18. Gary,

    Regarding changing the service account for a Service Instance. How do you change the service account using PowerShell for a service that does not have a direct mapping to a SharePoint Service Instance? For example, the 2 services “Microsoft Project Server Events Service 2010″ and “Microsoft Project Server Queue Service 2010″. These services are listed in the “SPCA–>Security–>Configure Service Accounts” and obviously I can change the account on that screen, but I would like to use powershell.

    Thanks!!

  19. So….what do I do when I accidentally enter a new managed account and then realize that some of my other services are failing because the person before put all the services in the same app pool :/
    It seems that the only option I have is to Create a completely new app pool in order to select a managed account. Is this the only option? Why is there not a way to select **use current application pool and then select a managed account that is already set up ?
    is there powershell that will allow me to change the application service account for the Managed Metadata Service?

  20. I am new to sharepoint, could any one help fixing this error.

    Server Error in ‘/’ Application.
    ——————————————————————————–

    Object reference not set to an instance of an object.
    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

    Source Error:

    Line 21: StringBuilder content = new StringBuilder();
    Line 22: content.Append(“”);
    Line 23: for (int index = 0; index 3 ? 3 : newUsers.Count); index++)
    Line 24: {
    Line 25: string value = newUsers[index]["College Name"].ToString();

    Source File: c:\inetpub\wwwroot\wss\VirtualDirectories\5954\UserControls\NewUsers.ascx.cs Line: 23

    Stack Trace:

    [NullReferenceException: Object reference not set to an instance of an object.]
    NewUsers.Page_Load(Object sender, EventArgs e) in c:\inetpub\wwwroot\wss\VirtualDirectories\5954\UserControls\NewUsers.ascx.cs:23
    System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +24
    System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +41
    System.Web.UI.Control.OnLoad(EventArgs e) +131
    System.Web.UI.Control.LoadRecursive() +65
    System.Web.UI.Control.LoadRecursive() +190
    System.Web.UI.Control.LoadRecursive() +190
    System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2427

  21. Thank you for this article. I suspect I am going to need to read it many times to understand it all.
    Right now, I have what I hope is a simple question. When setting up the crawl, I had to create a managed account. I created it and did not configure it to automatically change passwords.
    The service was created during the configuration process, and the managed account was added to the service – along with a password. As far as I know, that password was generated at the time the managed account was created. I do not recall providing a password when the account was created – am I mis-remembering this?
    The reason this is important is that the actual search service will not start – it says that the password is wrong. I didn’t think that I had set it. However, if I am mistaken, then I need to somehow change the password both at the managed accounts page and in the service.
    I just wanted to be clear about where the password came from in the beginning before I tried to change things.


Leave a comment

CAPTCHA Image

*