Changing SharePoint Admin Account Password

The scenario I'm blogging today is common for both SP 2010 & SP 2013. Also you can find so many blog posts written about changing SharePoint admin account password or changing SharePoint Service account password. One of the bests is from Todd Klindt which you can find here.
But what if you use the same admin user in two farms in two different geographical locations. Assume, we have two farms, one in US and another in Singapore two directory servers enabled with AD Sync. Your requirement is to change the password of the SharePoint Setup admin (SP_Admin) which is a managed user that has been used both in US farm and the farm in Singapore to setup SharePoint.

First you need to log in to one of the farms, go to central admin > Security > Config Managed Accounts. There you select the user, edit the settings and change the password of the user. Simple as that. :)
But what about the other farm? Same process won't work as you have already changed the password of the same user.

Log in to the second farm, fire up SharePoint PowerShell window with admin privileges. Type the cmdlet given below.
Set-SPManagedAccount -UseExistingPassword -Identity YourDomain\SP_Admin
This will save your day. But let's look into what goes behind.

SharePoint saves all Managed user passwords in config database. So when we change it in the first farm it saves the new password in the config database. But now considering the second farm, it still have the old password saved in the database. If you try to add a new password, SharePoint will compare the existing saved password with the current password (which we changed in the first farm) of the user and will not allow you to change the password from the second server.
So the easiest option available is to ask SharePoint to save and use the existing password of the user.
Hope this helps :)

Memory management with Start-SPAssignment

I was just playing around with some PowerShell and thought of writing a post on Start-SPAssignment cmdlet. This cmdlet is very useful if you work with memory intensive object as SPSite, SPWeb or SPSiteAdminstration. The default procedure is, with the use of a Get cmdlet it will automatically dispose these objects immediately and release the memory after the pipeline finishes.
But with Start-Assignment you can assign the list of objects to a variable or a global assignment store and dispose when no longer needed.

There are three assignment levels.

• No assignment  - where the object is not assigned to a object and is disposed after each iteration of the command.
• Simple assignment - This is done by using the global parameter. All objects are assigned to a global assignment store and released by calling the Stop-SPAssignment cmdlet.
• Advanced assignment - Objects are assigned to a named store and released by using the StopAssignment with -identity parameter. 

Technet Samples

Workflows for SharePoint 2013

Given below is the slide-deck from my session on Workflow which was held on 12th February. Your comments and feedback is much appreciated.

SharePoint Sri Lanka User Group – Workflow for SharePoint 2013

I’ll be speaking at SharePoint Sri Lanka User Group on Wednesday the 12th February 2014.

The session title is “Workflow for SharePoint 2013”. This is NOT a just another session on how to create simple workflows :) .Agenda is given below.

• History of Workflows
• Overview
• New Workflow Architecture
• Workflow Manager 1.0
• Visio 2013 & SharePoint Designer 2013
• Visual Studio Workflow
• Workflow Types
• Workflow Manager 1.0 in Depth

All are welcome. https://www.facebook.com/events/274981052658717/

Unable to open office files in Office client stored in SharePoint

One of my clients who is heavily using SharePoint Workspace 2010 faced an issue recently where some of the employees were unable to open the Microsoft Office files (word, excel, powerpoint files) in Office client applications. Files are stored in SharePoint and once they try to open the files in client application they get the below error.

 "could not open 'https://servername/Documents/CA_Project001.xlsx'"

So finally figured that this happens due to SharePoint Workspace temp files stored in the below location which are used for synchronising.

"c:\Users\login_user_name\AppData\Local\Microsoft\Office\14.0\OfficeFileCache"

Terminating the workspace process and cleaning the temp files sorted the issue. :)

Using PowerShell with Office 365

Given below are the quick steps to connect to your Office 365 site with PowerShell. As the first thing you need to download "SharePoint Online Management Shell". Get the correct version (x64 or x86) and run the setup.

Then run SharePoint Management Shell (if you have SharePoint in your machine) or SharePoint Online Management Shell.
In my case I already have a SharePoint Online site, if you don't, go to office.microsoft.com and give it a try.
After that go to the admin site and check the availability as it's the admin URL you need to connect to with the Connect-SPOService cmdlet.

With the credential parameter you need to pass a user with admin privileges to your Office 365 site. If it's one of your domain yours, make sure your domain is connected to the office 365 environment with ADFS.

It will ask for your password.

OK, the next thing is to find out the stuff you can do with PowerShell in O365. Simple, type cmdlet help SPO or Get-Command -Module Microsoft.Online.SharePoint.PowerShell in shell window.

Simply, you are through. Try out the listed cmdlets.

Installing and configuring Workflow for SharePoint Server 2013

When you open SharePoint Designer 2013 connected to a site to build a workflow, you will notice a new option called platform type. If it’s only “SharePoint 2010 Workflow” that you see, you need to install and configure “workflow manager”.

As MSDN recommends, you need to consider the following two key factors before configuring Workflow Manager to work with SharePoint Server 2013.

• Is Workflow Manager installed on a server that is part of the SharePoint farm?
• Will communication between Workflow Manager and SharePoint Server 2013 use HTTP or HTTPS?

These factors translate into four scenarios. Each scenario configures a SharePoint Server 2013 farm to communicate and function with the Workflow Manager farm. Follow the scenario that matches your circumstance.

1. Workflow Manager is installed on a server that is part of the SharePoint 2013 farm. Communication takes place by using HTTP.
2. Workflow Manager is installed on a server that is part of the SharePoint 2013 farm. Communication takes place by using HTTPS.
3. Workflow Manager is installed on a server that is NOT part of the SharePoint 2013 farm. Communication takes place by using HTTP.
4. Workflow Manager is installed on a server that is NOT part of the SharePoint 2013 farm. Communication takes place by using HTTPS.

Mine is the 1st scenario. Workflow Manager can be downloaded from here. Workflow Manager installation uses Web Platform Installer as shown in the below screen.

 
Then you need to install the prerequisites. 



Clicking continue will bring the configuration options.
 
I prefer to go with the custom setting as I can get to know what’s going on behind scene. If you select the “Configure Workflow Manager with Default Settings (Recommended)”, it will install a Workflow Manager farm. So let’s move with custom :)
In the below screen you need to specify the database server, where it will create the DBs needed for WM(Workflow Manager).

Make sure you remember or keep safe the Certificate Generation Key, as it’s needed when you want to add more servers to the WM farm.

Service account will be used to run the Application pool of the WM Website.
 
Below screen looks nice so added that too :D




Three screens below show the full configuration summary.



You can even see the full PowerShell script for the configuration.




Great!! You are done with the installation and the configuration of Workflow Manager. Yet one more step left for the Workflows to work in 2013 Platform. Open IIS Manager to see the WM Site and the port you configured.

Open SharePoint Management Shell with Admin rights and execute the below cmdlet (replacing the site and the Workflow Manager host site).

Register-SPWorkflowService –SPSite "http://www.whiteknight.com/Hr" –WorkflowHostUri "http://workflow.whiteknight.com:12291" –AllowOAuthHttp

Finally to check whether everything works fine… Open the above site (registered with workflow host uri) in SharePoint Designer 2013 and check the Platform type in workflow.

When you install Workflow Manager on a WFE it automatically installs the Workflow Manager Client on that WFE. You will still need to install the Workflow Manager Client on any additional WFE servers.