Event ID 1511 – Create SharePoint Service Account Local Profiles – PowerShell

​As per my post from yesterday, the guys who created AutoSPInstaller saved some coding for me by integrating a suggestion that they add local profile creation to the batch routines, in order to overcome the EventID 1511 error described by Sean on How to resolve event id 1511 windows cannot find the local-profile on windows server 2008/.

That’s great and all, however we not going to be using AutoSPInstaller exclusively for new SharePoint installs anytime soon. Something was still required for creating local profiles for service accounts in the case of hand-crafted installs, or in the case where we come upon SharePoint installs that have this error symptom pre-existing. So, I stripped the key functions required out of the AutoSPInstaller solution and created a standalone PowerShell that will create local profiles for accounts you specifiy by modifying the related Input.xml file (a stripped down version of the AutoSPInstaller’s AutoSPInstallerInput.xml).

My minimalist take on this is composed of two files, CreateLocalProfiles.ps1 and Input.xml.

CreateLocalProfiles.ps1

param
(
    [string]$InputFile = $(throw '- Need parameter input file (e.g. "c:\Input.xml")')
)

# Globally update all instances of "localhost" in the input file to actual local server name
[ xml ]xmlinput = (Get-Content $InputFile)
$Host.UI.RawUI.WindowTitle = " -- itgroove SharePoint Service Account Local Profile Creator --"

Function Get-AdministratorsGroup
{
    If(!$builtinAdminGroup)
	{
		$builtinAdminGroup = (Get-WmiObject -Class Win32_Group -computername $env:COMPUTERNAME -Filter "SID='S-1-5-32-544' AND LocalAccount='True'" -errorAction "Stop").Name
	}
    Return $builtinAdminGroup
}

Function CreateLocalProfiles([ xml ]$xmlinput)
{
	Write-Host -ForegroundColor White " - Starting up.."
	If ($xmlinput.Configuration.Farm.ManagedAccounts)
	{
		# Get the members of the local Administrators group
        $builtinAdminGroup = Get-AdministratorsGroup
		$AdminGroup = ([ADSI]"WinNT://$env:COMPUTERNAME/$builtinAdminGroup,group")
		$LocalAdmins = $AdminGroup.psbase.invoke("Members") | ForEach-Object {$_.GetType().InvokeMember("Name", 'GetProperty', $null, $_, $null)}
        # Ensure Secondary Logon service is enabled and started
        If (!((Get-Service -Name seclogon).Status -eq "Running"))
        {
            Write-Host -ForegroundColor White " - Enabling Secondary Logon service..."
            Set-Service -Name seclogon -StartupType Manual
            Write-Host -ForegroundColor White " - Starting Secondary Logon service..."
            Start-Service -Name seclogon
        }

		ForEach ($account in $xmlinput.Configuration.Farm.ManagedAccounts.ManagedAccount)
		{
            $username = $account.username
            $password = $account.Password
            $password = ConvertTo-SecureString "$password" -AsPlaintext -Force
			Try
			{
				Write-Host -ForegroundColor White " - Creating local profile for $username..." -NoNewline
				$credAccount = New-Object System.Management.Automation.PsCredential $username,$password
				$ManagedAccountDomain,$ManagedAccountUser = $username -Split "\\"
				# Add managed account to local admins (very) temporarily so it can log in and create its profile
	    		If (!($LocalAdmins -contains $ManagedAccountUser))
				{
					$builtinAdminGroup = Get-AdministratorsGroup
                    ([ADSI]"WinNT://$env:COMPUTERNAME/$builtinAdminGroup,group").Add("WinNT://$ManagedAccountDomain/$ManagedAccountUser")
				}
				Else
				{
					$AlreadyAdmin = $true
				}
				# Spawn a command window using the managed account's credentials, create the profile, and exit immediately
				Start-Process -WorkingDirectory "$env:SYSTEMROOT\System32\" -FilePath "cmd.exe" -ArgumentList "/C" -LoadUserProfile -NoNewWindow -Credential $credAccount
				# Remove managed account from local admins unless it was already there
                $builtinAdminGroup = Get-AdministratorsGroup
	    		If (-not $AlreadyAdmin) {([ADSI]"WinNT://$env:COMPUTERNAME/$builtinAdminGroup,group").Remove("WinNT://$ManagedAccountDomain/$ManagedAccountUser")}
				Write-Host -BackgroundColor Blue -ForegroundColor Black "Done."
			}
			Catch
			{
				$_
				Write-Host -ForegroundColor White "."
				Write-Warning " - Could not create local user profile for $username"
				break
			}
        }
	}
	Write-Host -ForegroundColor White " - Done Creating Local Profiles for Managed Accounts"
}
# Run the function
CreateLocalProfiles $xmlinput

Input.xml

<?xml version="1.0" ?>
<!-- General Instructions:
    1. If you use the characters ' " < > & in your configuration (e.g. in passwords) you should encode them as follows:

        '	&apos;
        "	&quot;
        <	&lt;
        >	&gt;
        &	&amp;

        For example <Password>Fd"je&f</Password> should be written <Password>Fd&quot;je&amp;f</Password>
    2. Configuration IS case sensitive.
    3. Use a validator like http://www.w3schools.com/xml/xml_validator.asp to check the syntax of your file.-->
  <!-- The Farm section contains basic farm-wide settings -->
<Configuration>
  <Farm>
    <!-- The ManagedAccounts section configures all accounts that will be have local profiles created for them. -->
    <ManagedAccounts>
      <!-- Add ManagedAccount nodes as required -->
      <ManagedAccount CommonName="spAdmin">
        <username>DOMAIN\spAdmin</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spFarm">
        <username>DOMAIN\spFarm</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spContentAppPool">
        <username>DOMAIN\spContentAppPool</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spMySitesAppPool">
        <username>DOMAIN\spMySitesAppPool</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spServiceAppPool">
        <username>DOMAIN\spServiceAppPool</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spSearch">
        <username>DOMAIN\spSearch</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spContentAccess">
        <username>DOMAIN\spContentAccess</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spUPS">
        <username>DOMAIN\spUPS</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spSuperUser">
        <username>DOMAIN\spSuperUser</username>
        <Password></Password>
      </ManagedAccount>
      <ManagedAccount CommonName="spSuperReader">
        <username>DOMAIN\spSuperReader</username>
        <Password></Password>
      </ManagedAccount>
    </ManagedAccounts>
  </Farm>
</Configuration>

Create SharePoint Service Account Local Profiles

1. Copy the .ps1 and the .xml file to SharePoint server in question.
2. Edit the input.xml in Notepad (following the notes in the comments regarding syntax) to reflect the names and passwords of the service accounts you need to create local profiles for. Yes, storing passwords in text files/PS scripts is bad and many people will say bad things. Do it anyways knowing that you are responsible enough to copy and delete a text file off a server after a patch. :) :

To add more accounts, just duplicate the node.

3. Execute the PowerShell in the SharePoint 2010 Management Shell (Start > Microsoft SharePoint 2010 Products > SharePoint Management Shell) by going to it’s folder in the command line and typing:

.\CreateLocalProfiles.ps1 -inputfile c:\input.xml

Obviously, adjust the folder path to the XML file as necessary.

4. The Script will run through and create your local profiles:

Credit again goes to BrianLala and the AutoSPInstaller project – he wrote this, I just stripped it out and re-jigged it.

Incoming search terms:

Modify Welcome Menu username Jquery

Needing to deal with grabbing the username displayed in the top-right SharePoint welcome menu and reverse the lastname, firstname format it was in, I came up with the following Jquery script.

It takes the welcome menu root takes in the style of “Smith, Joe” and turns it into “Joe Smith”, with having to mess with User Profile Synching or feature stapling. You could adapt it for any other need in a jiffy. The important thing to note is that grabbing the client side ID of the welcome menu is done with a wildcard expression, since the clientside ID is prone to changing – for example it could be “zz16_Menu_tt” one time and “zz12_Menu_tt” the next:

<script type="text/javascript">
ExecuteOrDelayUntilScriptLoaded(ReOrderUsername, "sp.js");
        function ReOrderUsername() {
		var userName = $('[id$=_Menu_t]').children("a").children("span").text();
		if(userName.indexOf(", ")!=-1) {	
		      var fnstart = userName.indexOf(", ", 0);
		      var fnend = userName.indexOf("<",fnstart);
		      var lastName = userName.substring(fnstart, fnend);
		      var firstName = userName.split(", ").pop();        
	              $('[id$=_Menu_t]').children("a").children("span").text(firstName + ' ' + lastName);
	         }	
        }		
</script>

Incoming search terms:

User Profile Synch SharePoint 2010 – The Essential Mix

While I detailed my findings on initial pre-deploy Best Practices in my post Planning SharePoint 2010 User Profile Synchronization, I have since banged out a more organized reading list figured out through more hands-on. You may start UPS in SP 2010 as confident pro but but you’ll end with the thousand yard stare, UNLESS you follow the exact advice presented by the nice folks in the following list, in the order indicated:

1. Make sure you have the SharePoint 2010 August CU (build 14.0.5123.5000 ). Todd Klindt’s complete SharePoint 2010 build number list is here. I personally can’t vouch for newer CU’s as I haven’t tried yet but will post in the future when I learn more about the stablity of those CU’s.

2. Read Technet’s Configure profile synchronization (SharePoint Server 2010)  end-to-end. Do not do the worksheets component at the beginning yet – we will get to those when the basic synch service is up and running smoothly. Do not execute any of the config suggested in that article yet- just breeze through it, familliarize yourself with the config sections they are referring to, but just don’t set anything up yet.

3. Read and execute the steps described on Spencer Harbar’s guide at http://www.harbar.net/articles/sp2010ups.aspx . As he indicates in his follow-up troubleshooting guide at http://www.harbar.net/articles/sp2010ups2.aspx you need to follow the instructions exactly:

I must stress that the number one reason people have problems is that
they do not follow the procedure! No really, I can’t count the number of
times steps have been missed or I get a response like “oh, I didn’t
think I needed to do that”. If you follow the procedure you will be
successful unless you are hitting an environmental or other known issue.

.. but wait! Not everyone is a super MVP like Spencer so a lot of the little details he refers to will actually be more complex for those who have perhaps have dived straight into SharePoint without a lot of Windows SysAdmin experience. So if you find gaps in your understanding of Spencers instructions, refer to the following article by Microsoft Support Escalation Engineer Steve Chen in point 4. Heck, read it regardless.

If you are at any point not clear on user accounts and rights, refer to Sean Wallbridge’s guidance on SharePoint 2010 Server User Accounts

4.
Steve Chens User Profile Sync articleIn particular sections like detailing how to Grant Replicating Directory Permission in AD will help people who are new to the SysAdmin.

5. At this point you should have your two ForeFront Windows services up and started, and be able to access Central Administration > Synchronization Connections etc. normally. If not, or something else has blown out, do not pass go, do not collect $200 : return to Spencers troubleshooting article and be very sad because you very likely did not pay close enough attention to the steps involved.

6. Read Technet’s Plan for User Profile Synchronization

7. Grab theUser profile properties and profile synchronization planning worksheets for SharePoint Server 2010, forget about being an environmentally friendly, paperless SharePoint zealot and print those suckers out. Post ‘em all over your cube, your bathroom, wherever. Make sure you run through them even if it’s not a mega enterprise deployment you are creating.

8. Deploy!

The preceding links are essential to avoid your first SharePoint 2010 User Profile Synchronization attempt turning into a headbanger where grown men stare anxiously at little service start status indicators.

 

Incoming search terms:

Expand the SP 2010 User Profile Info by Default

Out of the box, the SharePoint 2010 User Profile page uses a bit of Javascript to truncate the user’s bio info like Email, School etc. with a “more information” hyperlink that can be clicked to show all the info.  The user’s bio/description text is also similarly semi-hidden on page load.

The following quick CSS hack can make both these detail areas fully visible by default, and also hide the “more information” / “hide information” hyperlink”:

1. Open the file in a plain text editor or CSS editor of choice.:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033\STYLES\mysitelayout.css 

2. Paste the following CSS into
the bottom of the file:

/* IT Groove -
 Added to keep the Show More Information/About Bio dialog in an opened state
initially */

 #ctl00_PlaceHolderMain_ctl11_showHideLink
 {
 display:none;
 }
 .ms-contactcardtext3
 {
 display:block !important;
 overflow:visible !important;
 }
/*&nbsp; */

3. Save file. Users will have to press Ctrl-F5 or go into their browser and manually delete the file cache
for the changes to take effect. Avoid deleting users browser cookies when clearing cache to avoid frustrations, just clear the file cache.

Just remember, you’re modifying core SharePoint CSS which is most definitely not a best practice, but can do the trick for you in some circumstances!

Incoming search terms:

Planning SharePoint 2010 User Profile Synchronization

A basic issue – the client has their Active Directory DisplayName populated in the style of “LastName, FirstName“. Legacy business requirements dictate that the DisplayName stays in that format – but the SharePoint champion comes along and indicates that it would be preferable to have the SharePoint 2010 UI show the users DisplayName in the standard “FirstName LastName” format.

After quickly toying with the idea of using Jquery or some other front-end patch to just reverse the names – complications arose – number one being the data in the DisplayName field in AD was inconsistent, with various flavours and styles of data that was mashed together over the years. Active Directory is aptly named-  people will mess up this data actively. Not to be trusted.  The solution:

1. Set up the SharePoint 2010 User Profile Synchronization and use custom field mapping.
2. Create a new profile property in AD called customDisplayName and give it the values Firstname Lastname
3. Map the new customDisplayName property to the SP DisplayName property.

So, the end result should be that users would now see their DisplayName throughout the SP application populated with the AD field data “FirstName LastName
Getting User Profile Synchronization itself planned, configured and deployed is a big task. This post will let help you  plan out your first moves.

Authoritative initial references can be found at:

TechNet – Configure profile synchronization (SharePoint Server 2010):
http://technet.microsoft.com/en-us/library/ee721049.aspx
Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization:
  http://www.harbar.net/articles/sp2010ups.aspx
SharePoint 2010 – Provisioning User Profile Synchronization:   http://blogs.msdn.com/b/russmax/archive/2010/03/20/sharepoint-2010-provisioning-user-profile-synchronization.aspx

There are four Excel Worksheets available for download from TechNet which should be the best way to get things organized:

User Profile Properties Planning worksheet

( .xls download )
Should be used with the Plan user profiles, Plan for profile synchronization, and Configure profile synchronization topics on TechNet.

Connection Planning worksheet

( .xls download )
Specifies information that you will need to gather for each directory service with which you will synchronize profile information. It should be used with the Plan for profile synchronization and Configure profile synchronization topics on TechNet.

External Content Types Planning worksheet

( .xls download )
Should be used with the Plan for profile synchronization topic on TechNet if you need to synchronize user profiles with business systems.

Profile Synchronization Planning worksheet

( .xls download )
Profile sync worksheet tab of the specifies information that you might need to gather if you have not already configured the SharePoint Server infrastructure. It is used with the Configure profile synchronization topic on TechNet. The Property mapping worksheet tab is obsolete; it has been replaced by the User Profile Properties Planning worksheet.

NOTE: When performing the intital setup, it’s important to remember that MS best practice is to not have your Active Directory Domain Controller on the same server as SharePoint. So you need to follow a different path if you are using a dev server with AD and SQL all wrapped into the one server, than if you would be deploying to a production setup with AD DC on a separate server. Spence Harbar in particular notes this in a few places but it will confuse the hell out of you with the AD setup requirements unless you understand the distinct setup paths required for both scenarios.

Recent Comments

  • Keith Tuomi

    Ah party poopers – using the Wayback Machine it seems MS updated the official guidance on that page sometime after October 2013 to include the following new directives:

    -Don’t install any other server applications on the server that’s running Office Web Apps Server. This includes Exchange Server, SharePoint Server, Lync Server, and SQL Server. If you have a shortage of servers, consider running Office Web Apps Server in a virtual machine instance on one of the servers you have.

    -Don’t install any services or roles that depend on the Web Server (IIS) role on port 80, 443, or 809 because Office Web Apps Server periodically removes web applications on these ports.

Follow me on Twitter

Office 365 Service Health

There is a problem - it appears you are using categories and no feeds have been put into those categories.

SharePoint & Office Patches

There is a problem - it appears you are using categories and no feeds have been put into those categories.

VisualStudio.com Service Health

There is a problem - it appears you are using categories and no feeds have been put into those categories.