Clear cached Windows credentials

To manually clear any credentials cached on a Windows server or a workstation, go to command prompt and type

control keymgr.dll

From the window that opens, clear out any credentials you no longer need

Fun with Workflow Manager and SharePoint 2013

I've spent almost 2 days troubleshooting a pesky problem with Worklow Manager 1.1 and SharePoint 2013. I'll be honest, not  a big fan....product seems to be very finicky and not very well documented.

I was able to create the workflow farm using self-issued SSL certificate thanks to the truly outstanding blog by Spence Harbar that goes into great details on the inner workings of the product.

My issue was that after successfully connecting the workflow and SharePoint farms, I was able to create but not execute any 2013 style workflows. Workflows kept timing out with "canceled" status.

The actual error was:
"HTTP Unauthorized to https://mysite.mydomain.com ............sp.utilitity.ResolvePrincipalInCurrentContext"

After digging, turns out WF uses information from the user profile in order to authenticate the user. However, my UPS service app was running, UPS service was  up, and I was able to find the profile itself in the profile store. This is the sequence of steps that  fixed it for me:

1. Disconnect SharePoint farm from workflow farm: I usually delete the workflow service proxy in Central administration and any entries I see in the Security > Trusts (only the GUID-named one(s))

2. Delete and recreate the User Profile Service App

3. Recreate the AD import connection and re-import all user profiles (wait until this step completes before moving on)

4. Reboot all SharePoint and Workflow servers

5. Reconnect SharePoint to Workflow using "Register-SPWorkflowService......" use -force parameter here as the WF farm already has entry for your SharePoint farm

Finally, crack open SharePoint Designer 2013 and create new simple workflow to test (site or list based). I usually just get the simplest I can, such as manually kick one off, log message to the workflow history list and go to end.....one gets brain dead doing this 50 times while troubleshooting :).

Problem fixed, workflows are now executing. Hope this helps someone out there.

FAB40.....not so fabulous after SharePoint 2010 Upgrade

I don't mean to belittle the famous FAB40 templates, they were valuable addition to any MOSS2007 farm and users were writing poems, praises and a love song here and there in their honor. However, upgrading these farms to SharePoint 2010 come with their own set of problems.

When trying to do DB attach upgrade, I kept getting thousands of errors in the new farm, and lots of sites would simply not come up. After some googling, I run across Joel's post that suggests deploying the needed legacy FAB40 solution files, followed by hiding site templates and resolving duplicate content types.

BTW, if you are wondering how to hide site templates from your users (the easy way that is), go to C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\1033\XML and edit xml files deposited by these solution packages.

File names kind of match the solution, but the dead giveaway is DisplayCathegory="Application Templates" flag. Just change Hidden flag from FALSE to TRUE (on all WFEs that is).

Anyways, back to the reason for this post.....if you have good remedy for short-term memory problem, please do share :).

After the upgrade and the universe being at peace for a month or so, some user was trying to create site template and reuse it elsewhere. Creating a template would fail with:

Error exporting the site field named "Asset" 

Suspecting FAB40, I retracted all solutions from the farm, the error was gone, and site template creation started working OK.

As I was getting ready to pop the cork and call it a day, the most unfortunate news came in....now what!?

Yes, the site template is there but we are now getting this error when trying to create a site based on it:

The content type name ‘$Resources:er,ExpenseFormsTitle’ cannot contain: \ / : * ? “ # % < > { } | ~ & , two consecutive periods (..), or special characters such as a tab.

After playing with applicationtemplatecore.wsp solution package, I eventually realized that:

a) in order to create site template, the applicationtemplatecore.wsp needs to be RETRACTED
b) in order to use this site template, the applicationtemplatecore.wsp needs to be DEPLOYED

As much as I like looking at Central Administration, doing this every single time someone needs site templates just wouldn't cut it, so it was time to call the backup, aka Microsoft Support.
The guy I worked with was great and right on the spot.

So for all of you dear SharePoint admins, here's the solution (minus call to MS support):

1. deploy applicationtemplatecore.wsp

2. look for er.resx under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources

3. save it somewhere, and retract applicationtemplatecore.wsp (and the rest of FAB40 if you have them) - this will remove files from the folder

4. copy er.resx back under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Resources


As of right now, the fix looks promising and the universe is back at peace. But then, popping the cork on the champagne may anger the SharePoint gods, so for now I'll just keep it on ice.

User Profile Service Synchronization Timeouts

If there is one service application in SharePoint 2010 that's anything but boring, that's certainly the User profile Service App. I was recently building out a farm and after the UPS synchronization connection was successfully built, I tried importing user profiles form AD.

Looking at the  Forefront Identity Manager applet located at C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\Miisclient.exe , I noticed timeouts.

DS_FULLIMPORT step would start and after about 5-10 min would fail with stopped-connectivity error, WCF Endpoint failure.

I was on the phone with MS for couple of hours going through the logs, and trying to sync over and over (and over) again, each time being a failure.
The proposed solution was to increase timeouts values for service endpoints. Apparently, each SharePoint 2010 service has two endpoints (bindings), one for HTTP and another one for HTTPS, and their configuration files are located under:

C:\Program Files\Microsoft Office Servers\14.0\WebService


Now I am sure if you are a developer you probably already knew this, but infrastructure guys like myself don't often have to deal with the inner workings of web services. Anyways, this is where these files are located, and you are looking for web.config

Look for

There are two bindings: HTTP/HTTPS, 4 timeout intervals each: receive, send, open and close, all 20 sec by default. We had them increased to something like 5 minutes each. 


There are couple of more locations the same process was repeated:

C:\Program Files\Microsoft Office Servers\14.0\WebClients\Profile\client.config

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\WebClients\client.config 

Indeed, the UPS sync was more robust and did not time out as quickly as before. What I think ultimately was a fix (or part of the resolution at least) was very simple. I looked at another farm which was importing AD profiles OK, and compared the connections in Miisclient.exe side by side. 

Turns out, the farms were attaching to different domain controllers when trying to pull profiles, and my theory is that the problem child was looking at a DC that was either particularly slow, or at a distant physical location. 

I don't want to assume the latter, since I would think that any MS product would be site-aware and always use local domain resources based on SRV records and Domain sites and services subnet information. So I'll just blame it on a bad DC :)

All I had to do was to specify the same DC that the "good" farm was using, when building the synchronization connection in the "bad" farm. I never had to do that before, but hey, whatever it takes to get it fixed. After that, UPS Sync was running with no issues, and I was finally able to import my profiles.  

Change password for managed service accounts in SharePoint 2010

Sometimes you need to change service accounts password for a farm after it was built and configured for various reasons:

1. security team hounds you and you have to periodically change service accounts passwords

2. your SharePoint admin guy leaves the company and you don't trust him/her

3.consultant comes in and configures your farm (refer to number 2 above)

4. you are of the Chicago's school of thought "Vote early and vote often" and extend it to service accounts password security......

There are couple of blog posts out there that talk about how to change passwords for SharePoint 2010 manages service accounts. You can do it using the GUI (Central Admin) or powershell.

I actually had to go through this exercise recently, and what I found is that certain service applications will stop working after the passwords have been updated. Specifically, the user profile synhronization service stops (big surprise), and the search service application enters paused state.

After you change the passwords, you should probably check and make sure the underlying services are running. The two Forefront Identity Management services on which UPS depends will be stopped. Don't try to start them manually, instead do it through Central Administration > Manage Services on Servers. You will be prompted to re-enter the password for your farm account.

Additionally, you may need to update the password for SharePoint Server Search 14 service. In my case it was straightforward, I rebooted my index server and the service was stopped complaining of logon failure. I just updated the credentials in services.msc snap-in and started the service manually.

There is one more step to get search working again, and that is to resume the search service application from powershell.

Run get-spserviceapplication, this will give you list of all service app IDs.

Copy the ID for your search service app and then run:

resume-spenterprisesearchserviceapplication -identity .

This will resume the service app, and your scheduled crawls will start running again.

FAST for SharePoint Cluster Configuration

I spent considerable time last week trying to build 2-node FAST cluster for SharePoint 2010 implementation. it was my very first FAST cluster implementation, so cut me some slack people, will you. 

Creating the setup.xml file and building the admin FAST node was the easy part, but trying to connect the non-admin node is what took up most of my time.

(The default FAST installation creates 3 example files under C:\FASTSearch\etc directory, they are named deployment.sample.single.xml, deployment.sample.multi1(2).xml.  Most of the time you can tweak them to suit your needs instead of trying to create on from scratch.)

When running the configuration wizard, the error I kept getting was:

{drive}:\FASTSearch\bin\MonitoringServiceConfig.exe” Output – Error: The file ‘{drive}:\FASTSearch\etc\middleware.cfg’ was not found.

I searched through the blogs for quite some time, and I should here thank all the bloggers out there which provided useful information (including our very own David Sobiecki), links provided at the bottom here.This is the summary of things I did or checked for all in one place: 

1. Issue ncrtl status on the FAST admin node: we need to make sure all services show status running
2. Try running setfastsearchipsec -create on the non-admin FAST node: this will prompt connection to the FAST admin node and parsing the setup.xml file. Depending on the error reported it's usually either connectivity issue to the FAST admin node, or incorrect setup.xml formatting

3. Recreate the setup.xml file using notepad: apparently fancier XML editors add invisible characters that FAST configuration wizard doesn't like, so to be safe you should paste content on notepad and quickly proofread for any characters that are not supposed to be there

4. Disable firewall on the FAST Admin node: now I know this is not best practice, but in my case it worked. FAST configuration wizard will complain if the firewall is disabled, so I tried many combinations. Having the firewall enabled on the non-admin node and disabled on the admin node is what worked for me
5. Finally, unselect browser proxy settings (automatically detect settings, use proxy server etc.) on the non-admin node

Hope this summary will help other people who run into similar issue. 

Happy FASTing people!

If you feel inclined to read more, here is a list of blogs I used:

http://davemcmahon81.wordpress.com/2011/07/30/adding-a-non-admin-server-to-fast-search-for-sharepoint-2010-fails/

http://blogs.technet.com/b/speschka/archive/2010/05/25/solving-configuration-failures-with-non-admin-nodes-in-fast-search-for-sharepoint.aspx

http://blogs.msdn.com/b/scottos/archive/2010/07/16/we-need-to-talk-aka-it-s-not-me-it-s-you.aspx

http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/f80c1daf-50d0-4d33-84b5-c5533a6a129f

https://dotnetmafia.sys-con.com/node/1855150/mobile

http://blogs.pointbridge.com/Blogs/Sobiecki_David/Pages/Post.aspx?_ID=3

Fixing orphaned sitesFixing orphaned sitesTuesday, July 05, 2011

Before upgrade to SharePoint 2010 you may see orphaned sites reported in your upgrade logs. 

Now, stsadm.exe -o databaserepair is supposed to help you fix these references and get rid of the orphaned sites.  The keyword here being "supposed to"......If that fails, you can always find and delete these sites manually. 

First, enumerate all sites for a particular content database: 

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsa

dm.exe -o enumallwebs -databasename SharePoint_Home_Content >> C:\AllSites.txt

What we are looking for is  InSiteMap  flag set to NULL, indicating that the particular site in question has no parent site, and is therefore orphaned. This is the TechNet article article that  about it. 

Record the GUIDs of the orphaned sites, and delete them one by one, by running: 

stsadm -o deletesite -force -siteid < Orphaned Site Collection ID > -databasename

Then, run the following command to map the remaining copy to the site map:

stsadm –o refreshsitemap

Now, just run the preupgrade checker one more time, and as you see no orphaned sites tap yourself on the back  for job well done :).