Advancing Productivity and Operational Efficiency through Cloud Services and Apps



Changing SharePoint 2010 Managed Account Passwords with PowerShell

A SharePoint 2010 Managed Account, is essentially a Service Account whose credentials are managed by SharePoint, which can automatically change the password of the account based on a given policy / schedule. Check out the posting “Managed Accounts” in Bill Baer’s Blog for more detailed information.

While most of the configuration of managed accounts will likely take place in Central Administration, at some point you may need (or simply prefer) to change the password via PowerShell. Personally, I ran into the need, as my farm account password had been changed and the Central Administration site would not run.

I used the following PowerShell script to change the Managed Account password.

$ver = $host | select versionif ($ver.Version.Major -gt 1)  {$Host.Runspace.ThreadOptions = ReuseThread"}Add-PsSnapin Microsoft.SharePoint.PowerShellSet-location $home

$inManagedAcct = Read-Host 'Service Account'

$managedAcct = Get-SPManagedAccount $inManagedAcct

$inPass = Read-Host 'Enter Password' -AsSecureString$inPassConfirm = Read-Host'Confirm Password' -AsSecureString

Set-SPManagedAccount -Identity $managedAcct -NewPassword $inPass -ConfirmPassword $inPassConfirm -SetNewPassword

Click here to download the PS1 file. You may need to remove the first few lines that load the SharePoint PowerShell snap-in, if you intend to run the script from the “SharePoint 2010 Management Shell” console.

How-To Video: Changing Application Pool Accounts in SharePoint 2010

Yet another cool feature in SharePoint 2010 is the “Managed Accounts” concept. Once configured SharePoint can automatically reset service account passwords on a schedule, detect imminent password expirations and notify an administrator, and automatically propagate service account changes to all of the servers in the farm.

Check out the following TechNet article for more information: Plan automatic password change (SharePoint Foundation)

digg_url = “”;digg_title = “How-To Video: Changing Application Pool Accounts in SharePoint 2010”;digg_bgcolor = “#FFFFFF”;digg_skin = “compact”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;

BCS External List Error – Cannot Connect to the LobSystems (External System)

There are several good posts out there providing examples and step by step instructions on how to create external content types with SharePoint 2010 BCS. Unfortunately most fail to provide any warnings or guidance around Authentication; which should be, without a doubt, one of the most important things to consider. Most of these examples work flawlessly… until you try to view your external content type with another user account lacking some sort of access to the external system; and you encounter an error that resembles the following: Cannot connect to the LobSystem (External System)

Fortunately, the solution is likely simple… But you’ll have many thing to consider; what kind of access you need to grant to which accounts, do those accounts need to be mapped back to equivalent accounts in the external system, whether or not to map AD groups rather than individual accounts to accounts in the external systems, and many more that will quickly become apparent fairly quickly.

Of course if you are reading this post, you’ve likely ran into the error and are looking for a solution. Unfortunately there isn’t a one size fits all, and I wouldn’t necessarily consider it an error; more of a warning, a heads up, that you may have not thought the whole thing through. This will definitely be a subject upon which many best practices will come to surface. But, while I can’t give you the right solution for your particular scenario (there are many ways to skin this cat;) I should be able to point you in the right direction.

Chances are that if you followed one of the many posts which describe how to do this, you chose “Connect with User’s Identity” when creating your connection.



You’ll quickly come to realize that in most scenarios not all users have direct read or write access to external systems, often times they don’t even use a Windows Identity. Fortunately, our solution (or at least part of it,) is right under our noses:

If you are wondering what the Secure Store Application ID is, it refers the Secure Store Service, which you’ll want to do some reading on. I recommend you start here ( for a short but good description, and follow up here ( for detailed steps on how to set it up.

Essentially, you’ll need to create a Secure Store Service Application of type “Individual” or “Group” with several options for each. An application of type “Individual” will require you to map each user to a unique set of credentials (there is an option to create a page from where users can specify there own credentials.) An application of type “Group” will allow you to map a unique set of credentials to a specific AD Group; I suspect this will be the most common scenario.


You’ll then be prompted to configure the various fields which may be required to provide credentials to the external data source. If the external system uses Windows Authentication, the default ones should work just fine.


Next, you’ll need to specify the administrators and members of the target application (read the description of each carefully)

Finally, select your application and specify the credentials that will be used to connect. The Secure Stored Service Application will use these credentials whenever anybody from the specified group tries to connect to the external system.


Now, reconfigure your connection to use the ID of the Secure Store Application in my case “My Secure Store Application”, perform an IIS Reset, and you are likely done.

If by any chance you are not, and instead you receive: “Access denied by Business Data Connectivity.” You’ll need to go to Central Admin > App Management > Manage Service Applications > Business Data Connectivity; and grant your users access to your External Content Type.


digg_url = “”;digg_title = “BCS External List Error – Cannot Connect to the LobSystems (External System)”;digg_bgcolor = “#FFFFFF”;digg_skin = “compact”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;

Solution to: “An error occurred while accessing SharePoint AddGallery, Please Try Again” on SharePoint 2010

I ran into the following error while creating a SharePoint library while trying to troubleshoot a completely unrelated problem: “An error occurred while accessing SharePoint AddGallery, Please Try Again”


Not very descriptive. A quick look at the event viewer revealed the following Warning:

Alternate access mappings have not been configured.  Users or services are accessing the site http://imapc with the URL http://localhost.  This may cause incorrect links to be stored or returned to users.  If this is expected, add the URL http://localhost as an AAM response URL.  For more information, see:″/>”


Of course accessing the site via the correct Url is the easiest way to solve it. If you need to add the Alternate Access Mapping, you can do so from “Central Administration > Application Management > Configure Alternate Access Mappings”


digg_url = “”;digg_title = “Solution to: “An error occurred while accessing SharePoint AddGallery, Please Try Again” on SharePoint 2010”;digg_bgcolor = “#FFFFFF”;digg_skin = “compact”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;

SharePoint 2010 on Windows 7 Exception – UserProfileException: Unrecognized attribute ‘allowInsecureTransport’

If you tried installing SharePoint 2010 Beta 2 on Windows 7 (or Windows Server 2008 R2) shortly after its release; you may have ran into the following error:

Failed to create sample data.
An exception of type Microsoft.Office.Server.UserProfiles.UserProfileException was thrown.  Additional exception information: Unrecognized attribute ‘allowInsecureTransport’. Note that attribute names are case-sensitive. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\Profile\client.config line 56)
Microsoft.Office.Server.UserProfiles.UserProfileException: Unrecognized attribute ‘allowInsecureTransport’.

This error is caused by a known issue with Token Authentication and WCF. A fix has been released and is now available  at

If you didn’t uninstall after receiving the error, simply install the hotfix, and re-run the SharePoint 2010 Products Configuration Wizard.


digg_url = “”;digg_title = “SharePoint 2010 on Windows 7 Exception – UserProfileException: Unrecognized attribute \’allowInsecureTransport\'”;digg_bgcolor = “#FFFFFF”;digg_skin = “compact”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;

Moving All SharePoint Databases to a New Server

The SharePoint team has released a new procedure on how to move SharePoint databases across servers. Until they are able to do so, it is available in the Microsoft download site at:

There are 2 separate procedures and both can be downloaded on the same page. One for moving databases to a server with the same name, and one for moving databases to a server with a different name.

Remember, This procedure is meant to move “ALL” SharePoint Databases to a new server. However, they are not able to publish it on TechNet at the time.

Retrieve the IUSR (Anonymous) password using the IIS Resource Kit Metabase Explorer

Just recently, while troubleshooting an 401 Unauthorized error on an FBA site in SharePoint, I discovered that someone accidentally changed the password of the IUSR account (IIS Anonymous User) on one the IIS Web Sites.

The error in the browser was “HTTP Error 401.1 – Unauthorized: Access is denied due to invalid credentials.” I’ve blogged about this sort of error before, and there can be many culprits. But having gone over the scenarios I know of that might cause this with no luck, I decided to look at the Event Viewer Security logs.

I quickly discovered a series of Failure Audits with event IDs 680, 529, 539. Event ID 529 was the one that caught my attention:

Logon Failure:
     Reason:        Unknown user name or bad password
     User Name:    IUSR_…

The problem was very apparent; there was an issue with the credentials being supplied by the IUSR account. I tested with another number of sites non of which generated the error, so it was definitely isolated to this particular web application (IIS Web Site). I verified the User Account and it was fine, so it had to be the password. I searched the web for a way to retrieve the IUSR account password and everything seemed to indicate that I should use the adsutil.vbs script (which works well, just remember to change “IsSecureProperty = True” with “IsSecureProperty = False“.) But I also saw a comment referencing the “Metabase Explorer”; very cool.. something that would let me browse through the IIS Metabase.

I downloaded and installed the IIS Resource Kit and used it to retrieve the password of the IUSR account (IIS Anonymous User.)

After installing the IIS Resource Kit, follow these steps to retrieve the IUSR password using the Metabase Explorer:

  1. Open the IIS Metabase Explorer by going to Start > All Programs > IIS Resources > Metabase Explorer > Metabase Explorer
  2. Go to the “View” menu and click on “Secured Data”  (this will make sure the password is not displayed as asterisks) and Inherited Data (this will display any data that the web site is inheriting from the default)


  3. Expand the W3SVC Branch
  4. Expand the Branch of an IIS site that is running anonymous access

    Note: To determine the ID of the IIS Site; select the “Web Sites” node in IIS and look for the Identifier column in the right pane.

  5. Select the “Root” node and look for the AnonymousUserPass property in the right pane.

Create a free website or blog at

Up ↑

%d bloggers like this: