Category Archives: MSCryptic

SharePoint 2010 | Event ID 1511 – Windows Cannot Find The Local Profile for Application Service Account

During a review of the SharePoint farm health, I was seeing a lot of these errors in the event logs. The farm itself was still functional, but these errors were filling the event logs. The account is question was the same one that was used for the IIS website application pools. And while seemingly innocuous, it always bugs me to see these error events in the logs.  And as always with SharePoint and how MSCryptic the error handling is, there is always the possibility that things were not quite working right somewhere under the covers.

If you look in your event logs, you should see something similar to the following:

Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Date: 11/19/2013 10:05:07 AM
Event ID: 1511
Task Category: None
Level: Error
Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.


For some reason, my User Profiles on the Windows Server 2008 R2 is experiencing issues where the accounts cannot create local profiles but creates a Temporary user profile for the account used for the SharePoint website application pool.


While investigating the issue further, I also found that if I actually tried to log into the server using the service account ID I ended up locking up the server with a “Please wait for User Profile Service” message that was displayed indefinitely (Don’t try it unless you have someone around who can give the server a one-finger salute to perform a hard reboot). Research on the internet seemed to point to IP6 issues, but after trying all the suggested fixes I was still experiencing these issues.

Instead, this approach seemed to work well for me. The user profile now comes up as local in the User Profiles settings and the error have gone away for the time being.

If you are experiencing the problem:

1. Open Services, stop and then disable IIS Admin Service so that the application pools do not lock the profiles.


2. Open the Server Manager, Web Server, and right click on the Server. Select Stop.


3. Now open a command window (Start-Run-> type “CMD” ) and in the window type the following:

net localgroup administrators DOMAIN\AppPoolAccount /add

runas /u:DOMAIN\AppPoolAccount /profile cmd

4. After the second command, you will be prompted to enter the password of the DOMAIN\AppPoolAccount and when you hit enter it will launch a new window. In the window type the following to confirm the user profile directory

echo %userprofile%

5. Launch the User Profiles dialog or check “C:\users” to verify that the directory for your application pool account ID has been created.


6. Close the second command window, and in the original one type the following to remove the app pool account from the administrators group.  For whatever reason it only needed to be there to create the local profile and it’s not best practices or recommended that you leave the account as an admin on a production farm.

net localgroup administrators DOMAIN\AppPoolAccount /delete

7. Exit the command window

8. Start the Web Server

9. Enable and then Start the IIS Admin Service.

If everything has gone well, you now have one less Error event showing up in your server’s event logs.  I did not need to perform a server reboot to get rid of the error, but mileage may vary depending on your own farm’s configuration and what else you may be using these service accounts for.

Windows Server Essentials 2012–Install on Windows 8 OEM Machine

So I had a bit of fun over the weekend.  I have an old HP MediaSmart sever that ran Windows Home Server (WHS) which finally took a turn for the worst and just stopped with the continuous blinking blue light on boot.  I tried a couple of things from the forums, but this was not the first time the system had frozen up on me and I was expecting its eminent demise.  I had at least been smart enough when this happened last time to move all my shares over to an external USB and was ready for when I needed to move my data to a new computer I could just unplug the USB and attach to the new server.

Last weekend I took the plunge.  Back in the day when I was a big hardware geek I probably could have built out my own server.  These days most hardware for home use is good enough, and for a home server generally most desktop OEM systems are good enough for my needs, so why go to the extra trouble and expense of piecing together a system?  I went to CostCo and picked up a nice Dell system, i5 processor running 3.0 GHz with 4 cores and 8GB of RAM on sale for $550 (Which by the way is very quiet, my USB external drives make more noise than this little machine). Plenty of power to run the Minimum requirements and just touching on the recommended configuration to support maximum users and device limits ( ), plus it has a video card so I can plug a monitor in, install VMware and P2V my 2 core, 4 GB RAM laptop which mostly sits on my desk so I can check e-mail and surf the web (Makes the wife happy because she get’s the hand-me-down upgrade from her current netbook).  When I need a Windows 8 desktop I can bring it up and when I don’t I can give the resources back to the server.

Dell Inspiron 660 Desktop, Intel® Core™ i5-3330 3.0 GHz


Everything was going well, I unboxed the machine, plugged it in and went to install WSE over the Windows 8 OEM OS that was already there.  This is where I ran into a little thing called Unified Extensible Firmware Interface (UEFI).  As it turns out, one of the features of UEFI is that it contains a key the OEM manufacturers can embed into the BIOS.  Turns out that Microsoft’s Windows 8 requires not only a unique activation key for each PC / tablet, but requires OEM producers to insert the activation key directly in the device’s BIOS, delivering the product preinstalled with the operating system. Moreover, OEMs get the activation keys directly from Microsoft, eliminating the possibility of illegal use of OEM licenses for Windows 8.  Great for Microsoft, but for us poor home users trying to install WSE 2012 we keep getting this little message:

The product key entered does not match any of the Windows images available for installation. Enter a different product key

Which would be fine if it then prompted me for my WSE 2012 product key, but it doesn’t.  The installation just stops.

After much forum searching, I finally found the answer – embed the key in the installation media.

You can do this by placing a PID.txt file in the \sources directory of the installation media (Which means of course that installation using DVD is out, I had to image my .ISO to a bootable USB fob and make the changed there)

AFTER I had figured all of this out and finally got a clean install to the Windows 8 OEM box, I found this Fast Publish article from Microsoft which explains the issue and the resolution in detail:

Which of course stated my problem exactly:

This problem can occur if the supplied product key does not match the media that is being used to install Windows. The supplied product key may be in an unattended file, in the EI.CFG file, in the PID.txt file or in the firmware of the BIOS. Windows 8 OEM machines ship with the product key in the firmware, and if that product key does not match the media then you will see the error message from above.
For example: Installing a Windows Server 2012 on a Windows 8 OEM machine is likely to cause this problem.

So the solution was to drop a PID.txt with the product key specified on the USB fob that had my WSE 2012 installation:

But seriously, Microsoft couldn’t just skip all this hassle by having the installation prompt for a key if the BIOS key doesn’t match what the end user is trying to install?  Seems like as we go down this road the non-techies who get a hand-me-down computer and try to upgrade the OS are in for a lot of problems if the BIOS key doesn’t match the OS they want to install.  I can see a serious flaw in tying to OS to the computer without giving the end user an opportunity to enter a different key in the install UI, but then again maybe this is similar to Apple’s model of “if you want the new OS buy a new computer” and non-techies will just shell out the cash for new OEM hardware rather than dealing with the hassle of figuring out how to get the right key to work with the installation/upgrade.

PowerShell 3.0 (KB2506143) and SharePoint 2010, Not There Yet

So a bit of a rant, but as it turns out installing the Windows Management Framework 3.0 (KB2506143) on a SharePoint 2010 server is not such a good idea.

After installing the Windows Management Framework 3.0 on a SharePoint 2010 Server I can’t use the "SharePoint 2010 Management Shell" anymore.  SharePoint uses .NET 3.5 and PowerShell 3.0 uses .NET 4, so when I try to open the SharePoint management console and run a SharePoint cmdlet I get some fun errors that Microsoft SharePoint is not supported by Version 4.0

A PlatformNotSupportedException occured while trying to acquire the local farm: System.PlatformNotSupportedException: Microsoft SharePoint is not supported with version 4.0.30319.586 of the Microsoft .Net Runtime. at Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Farm() at Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& farm, Boolean& isJoined)

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

So thanks for the lack of warning… but the fix is easy enough:

  1. Open the Installed Updates on the server
  2. search for KB2506143
  3. Uninstall
  4. Reboot
  5. Open PowerShell and type “(Get-Host).version”, you’ll see it is now running in 2.0 mode again.

You would think that during the install process of the WMF 3.0 it might check for SharePoint components and at least give a warning, but as the PowerShell team says here:

Posted by Microsoft on 6/7/2012 at 12:34 PM

This is not an issue with Windows PowerShell. This is an issue with SharePoint 2010. The SharePoint team is aware of this compatibility issue and plans to address it in an upcoming release or service pack.

Fast Search – Failed to initialize session with document engine: Unable to resolve Contentdistributor

At a client site FAST suddenly started having problems with crawling data sources, they would continue to crawl indefinately and when trying to stop them they would sit in a “Stopping” status for hours and hours without ever actually completing a crawl or loading any documents into the index.  Reviewing the event logs turned up this error:

Failed to initialize session with document engine: Unable to resolve Contentdistributor

Having worked fine for about a year we could not find any significant changes that were made to the system that would cause this behavior… and that’s when the little lightbulb went off that it had been almost exactly a year since this server was set up…

During installation on development servers a self-signed certificate can be created for communication between FAST and SharePoint. It turns out that the self-signed certificate is only valid for one year and when it expires the above problems will occur. Unfortunately there is no mechanism making it obvious to the user that the certificate has expired, thank you MSCryptic… The fix is to generate and deploy new self-signed certificate and this can be achieved with the following steps:

  1. Make sure the FAST Search for SharePoint & FAST Search for SharePoint Monitoring windows services are stopped.
  2. Open the FAST PowerShell on the FAST server as an administrator.
  3. Navigate to the FAST directory (i.e. <FASTSearchFolder>\installer\scripts)
  4. Run the following command: .\ReplaceDefaultCertificate.ps1 -generateNewCertificate $true
  5. This will generate a new certificate, valid for one year in the following folder: <FASTSearchFolder>\data\data_security\cert\FASTSearchCert.pfx
  6. This certificate will need to be copied to the SharePoint server (if running a multi-server environment).
  7. Start the FAST Search for SharePoint & FAST Search for SharePoint Monitoring windows services.
  8. Now the certificate needs to be loaded on the SharePoint server.
  9. Open the SharePoint PowerShell as an administrator on the SharePoint 2010 server.
  10. Navigate to the location of the SecureFASTSearchConnector.ps1 script (this script may need to be copied from the FAST server as mentioned in step 6).
  11. Run the following command (userName should reflect the details of the user running the SharePoint Server Search 14 (OSearch14) windows service):.\SecureFASTSearchConnector.ps1 –certPath “path of the certificate\certificatename.pfx” –ssaName “name of your content SSA” –username “domain\username”
  12. Don’t foreget that at this point you’ll be prompted for the cert password used when you initially set up FAST, so have it handy.

Assuming there were no errors when running the PowerShell scripts the SharePoint server certificate has been deployed and will be valid for another year. The content sources will begin working normally again.