SharePoint 2010 Development Machine with Office 2013

If your trying to setup or change the configuration of SharePoint on a development machines which has Office 2013 install you may encounter some strange errors relating to types such as:

Failed to call GetTypes on assembly Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c. Could not load file or assembly ‘Microsoft.Office.InfoPath, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.

This is related to the way in which SharePoint is loading certain assemblies and struggles with the new assembly for InfoPath. Thanks to Hermanote for the workaround which is to remove the InfoPath feature from office only, and the error goes away.

SharePoint 2010 State Service Database

I recently found a small bug in the SharePoint 2010 PowerShell comlets for creating the state service database using “New-SPStateServiceDatabase”.

You will receive the rather unhelpful error message “Operation is not valid due to the current state of the object”. I believe this is a generic WCF error as that’s all I was able to find when researching what may cause the problem. However, it later transpired that this was because I was trying to use a database alias (or potentially database server) which SharePoint isn’t currently aware of, as using the alias (or database server) that was used for the initial farm setup didn’t result in the same issue.

Its taken me a while to find this one as the state service isn’t usually one of the first service applications I configure, so it appears most of the other service application creation cmdlets don’t mind registering a new database host, but for some reason this one does!

If you use sql alias (as a best practice you should) and have a different alias for service applications, I would advise creating another service application before creating the state service database in order to make sure SharePoint is aware of the alias/dbserver.

Lync 2013 – Front End Server ‘Starting’

Upgrading Lync to 2013 recently I came across a problem where the front end service simply wouldn’t start but would get stuck in “Starting” mode.

I spent quite a bit of time trying to figure out what the problem was and got caught up in some false information on the technet forums that it was related to Server 2012. In fact the problem was fairly simple if you know whats going on under the hood.

When the server firsts starts it synchronises user information from active directory, but here’s the kicker, if you have multiple domains in your active directory forest regardless of where the server lies, it will try to get user information from the other domains, if it can’t it won’t start, and in most cases you have probably like me only run the domain preparation step on the domain you want to use with Lync.

There’s two ways to resolve this depending on your requirements,

  1. Run the domain preparation step on all domains in your active directory forest.
  2. (My Preferred) Limit the user replication to the domain you want to use with Lync with the following powershell:
    Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContextList @{Add="dc=fabrikam,dc=com"}

The PowerShell included above will limit the replication to the “fabrikam.com” domain only, misleading as the command may be (‘Add=’) as default the value is null (you can check with “Get-CSUserReplicatorConfiguration”) which essentially means all domains.

I didn’t find this issue to be that well documented or resolution 1, so hopefully this will help anyone else out there who has the same problem (and maybe remind myself if I ever want to include additional domains and can’t figure out why I can’t enable the users for Lync).

Big thanks to “JMTTech” on the technet forums for this one http://social.technet.microsoft.com/Forums/nb-NO/lyncserverpreview/thread/07ec9d8c-b83e-4795-91b6-0d3344cd49e5

SharePoint 2013 Pre-Requisites Configuration Error on Server 2012

As I started to configure our new SharePoint 2013 farm today I came across a problem when running the pre-requisites tool when it was attempting to install “Application Server and IIS Web Server roles” which resulted in very little in terms of error messages apart form “configuration error”.

After much searching and reading on Technet I wasn’t able to find out exactly what roles and features needed to be install so I could do this step manually. I resorted to simply adding most of the features I assumed would be needed based on what I remembered from a preview version install and discovered that it was due to .Net 3 not being present on the default install of Windows Server 2012. In order to install .Net 3 you have to have the original disk (or network location) where the files are stored in “:SourcesSxS”.

After I managed to install .Net 3 manually, the pre-requisites tool then progressed as expected.

UPDATE: This was incorrect, see below instead
If you are looking to install SharePoint 2013 on Windows Server 2012 I would recommend leaving the Windows Server 2012 disc in the drive or mounted, and using the new “mount iso” capability in 2012 to mount the SharePoint 2013 media so that the default sources location is available. If however, you end up in a similar situation, simply install .Net 3 manually using the “Add Roles or Features” as normal and this will prompt you to specify a location where the Side By Side files can be found.

I will hence forth refer to this as “SharePoint 2013 Gotcha #1″ (Although technically its Windows Server 2012 being difficult)

Update: I had an opportunity to check this again and found that having the disc in the drive simply isn’t enough. Manually install the following using “Add Roles and Features” and specify the SxS (Drive:SourcesSxS of install media) location when the notification appears in the roles and features wizard:

  • .Net Framework 3.5 Feature
    • .Net Framework 3.5
  • Web Server (IIS)
    • Web Server
      • Application Development
        • ASP.NET 3.5
        • .NET Extensibility 3.5

Coffee Break: Windows Server 2012 First Look

One of the key things I’m liking with Windows Server 2012, is the new Server Manager. The new version is alot more useful than that of Windows 2008 and Windows 2008 R2 in that it appears to work out of the box, where as the previous involved alot of “tweaking” to get WinRM working.

This has a huge impact on the use of Server 2012 Core Edition, which unless you love doing everything on the command line or in PowerShell is pretty annoying to even get started with. However, the new server manager allows you to add roles and features from your local workstation along with launching applicable role tools right from the UI.

I’ve always likes the idea of Windows Server Core, but the practicality of managing it has always been and issue along with role limitations, although this appears to have also been “fixed”.

So far so good…

Unable to use SQL Aliases in IIS Manager or Visual Studio

I Have always had a problem with IIS Manager using SQL Aliases when using the built in .Net membership providers (mainly cause its handy to test and setup the initial FBA user) but never managed to get down to the cause of the issue, just took it as one of those things.

Luckily it was never really that important to resolve so it got left as specifying the alias in the web.config file did appear to work fine. However, a colleague had a similar problem with Visual Studio when trying to regenerate a database layer, which was a bit more of an issue due to the storing of the string.

After a bit of googling we managed to track down the issue:

If like me your happy using the “cliconfg” command to specify aliases (mainly because its included in Windows Server 2008 R2 and there’s no need to install the SQL Native Client manually), its important to understand that the architecture is important, this is where “Native Client” should have given the hint. The problem is that the 32bit client and the 64bit client store their registry keys in different locations, therefore adding an alias in one doesn’t add it to the other. IIS Manager and Visual Studio are both 32bit applications and therefore use the 32bit aliases, however running the “cliconfg” command from run or a command prompt on a 64bit machine unsurprisingly loads the 64bit version of the client configuration tool. Therefore, if you run into this issue, you should run “c:WindowsSysWOW64cliconfg.exe” for the 32bit version.

Note: I have no idea why 32bit applications are stored in SysWOW64 and the 64bit ones in System32… appears like it should be the other way around to me?!