Thursday, 13 May 2010

SharePoint 2010 - New Service Application - Application Pool Already Exists!


Whilst playing around with SharePoint Server 2010 there have been a number of occasions where I’ve created a new Service Application, only to find I’ve either done it wrong or need it configured in a slightly different way for whatever reason.



Typically what I’d do is delete the old SharePoint Service Application and create a fresh one. I quite often want to use the same naming convention and this seems to cause problems.



For example, I created a Secure Store Service, realised I’d done something wrong, deleted it and tried to re-create it using the same settings as before. When I try to do so, SharePoint tells me that there’s already a SharePoint IIS Application Pool (SPIisWebServiceApplicationPool) that exists with the same name:

 


 

So the first thing you think to check is IIS, right? I did that and did not see the Application Pool to delete it.


Not accepting defeat and wanting to retain my naming convention I looked into this a little further; Is SharePoint 2010 storing a list of Application Pools somewhere and not clearing them out properly?


After a little searching, it struck me that perhaps this was something I could sort out with PowerShell. Here’s how:-
I queried the list of Application Pools using Get-SPServiceApplicationPool to ensure the one I’d previously created was indeed still there and accessible to PowerShell

 


 

Then it’s as simple as calling Remove-SPServiceApplicationPool to remove it.

 


 

That's it. You've tidied up the the farm by removing the application pool and got to keep your precious naming convention. Thanks PowerShell - I'll sleep easy now.

Wednesday, 25 November 2009

Windows Server 2008 R2: Active Directory Domain Services - Installation Failed

If, like me, you installed Windows Server 2008 R2  and then went on to disable several of the windows services you thought you didn't need prior to installing the Active Directory Domain Services role - you may have noticed that the Installation Fails.

I usually disable services that I feel are not required for what I'm doing. This especially helps create an optimal system when using a virtual machine.

However - learn from my mistake: Don't disable Remote Registry.

Remote Registry is a dependency of DFS Namespaces which is a dependancy of Active Directory Domain Services. Make sure these two services are enabled and you won't experience the same Installation Failed message.

Monday, 21 September 2009

SharePoint Designer: Errors were found when compiling the workflow

The Issue
Recently, while attempting to publishing a SharePoint Designer workflow I was receiving the following error message:

“Errors were found when compiling the workflow.The workflow files were saved but cannot be run”.
Detail: “Unexpected error on server associating the workflow”

I researched the issue and found many suggestions and workarounds for this issue. Fixes and workarounds that worked for others range from Permissions configuration, configuring the correct task list, right through to code fixes. On some occasions the problem was purely a minor detail that had been overlooked by the developer.

Knowing that none of these fixes and workarounds applied to my scenario I was a little baffled to say the least.

What worked for me
A colleague of mine suggested using ProcessMonitor (opens in new window) to find out what was happening when attempting to publish the workflow. What we discovered is that each time I tried to publish the workflow, it was writing to and referencing a cache on the client machine (where SharePoint Designer is running).

Cache Location on Vista/Win2008:- C:\Users\[Username]\ApPData\Local\Microsoft\WebsiteCache

Note: If you happen to know where the cache is located on other operating systems I’d appreciate your input.

Having cleared out the cache the workflows published. Hurrah!

Thursday, 14 August 2008

ECTS & ADAM Gotcha

The Extranet Collaboration Toolkit for SharePoint (WSS v3.0 & MOSS 2007) has a little gotcha which is rather annoying. The gotcha is an auto-append of CN=Users to the LDAP Connection String to the SharePoint web.config file. Here's how it tripped me up...

When configuring the ADAM instance, you are asked to input a User Container Name in the form of part of an LDAP connection string (see screen-shot below):

What this does is create an ADAM instance and a container at the path specified (User Container Name). When the ADAM instance is created, it also creates a sub-tree of CN=ExternalUsers, as shown below:

Now, when you run the ECTS setup wizard to configure and install the SharePoint solutions and features, you are asked to input an ADAM Server Name, you're then asked to provide a User Container Name at which to point the SharePoint solution to enable it to add the LDAP Connection string to the SharePoint web.config file.

Now here's where the gotcha hits - I looked at my ADAM instance using ADSI Edit and supplied the ECTS Setup Wizard with a User Container Name something along the lines of CN=Users,CN=ExternalUsers,DC=server,DC=domain,DC=suffix.

Now, when the ECTS Base feature is activated, it puts several items into the SharePoint web.config file. One of these items is the LDAP Connection String. What I didn't know at that time is that it automatically prefixes CN=Users to the User Container Name that you chose when configuring ECTS for SharePoint.

Given that I specified a User Container Name of CN=Users,CN=ExternalUsers,DC=server,DC=domain,DC=suffix when configuring ECTS for SharePoint, this would of course then become CN=Users,CN=Users,CN=ExternalUsers,DC=server,DC=domain,DC=suffix
(note the repeated CN=Users).

For a while, I manually updated all of the web.config files in my farm that were affected by this. Soon it became quite a burden; every time a modification was made that involved the web.config being re-written from the database, the repeated CN=Users would always re-appear.

I suppose you could put this down to my ignorance, or perhaps you'll agree with me that the documentation doesn't make this as clear as it should be - whichever way, I thought it might be useful to share this.