SharePoint Blog

I know there are a lot of posts out there that will guide you through the setup of a SharePoint 2013 development environment. So does it really needs another one? Well, maybe I searched with my eyes closed or I just have a very exotic idea of what my SharePoint 2013 development environment must look like:

Windows Server 2008 R2 with SP1 that is Active Directory Server at the same time

SQL Server 2008 R2 with SP1

SharePoint 2013 RTM

Visual Studio 2012 with Office/SharePoint App Development extensions

Disclaimer: I’m quite sure that with the hacks I promote in what now follows I am far beyond supported terrority … But it works!

I started by creating a Hyper-V virtual machine on my notebook with 8 GB, meaning that I had only 6 GB to spare for my virtual development environment. Without knowing I had digged myself one deep hole! Below I’ll provide a detailed list of all the steps I eventually took to jump over the deep hole (incl. pointers to other websites that turned out to be extremely valuable). However, first I’ll present you with a brief overview of all the problems I initially ran into:

AppFabric’s Distributed Cache doesn’t like it when you have less than 10% of physical total memory available and hence will you’ll see many errors like “The Execute method of job definition Microsoft.Office.Server.UserProfiles.LMTRepopulationJob” appear in your event viewer.

Most SharePoint Web Services cannot be activated as they require at least 5% of total memory and you’ll find many errors like “WebHost failed to process a request (…) Memory gates checking failed because the free memory (139665408 bytes) is less than 5% of total memory”.

To make the Farm Account a local administrator on a server that is Active Directory’s Domain Controller is not as straight forward as you may think.

Don’t be smart and use the local administrator’s account as Farm Account because the System Account is not allowed to deploy Apps to SharePoint (and you cannot debug/deploy SharePoint hosted Apps to your local SharePoint if you don’t run Visual Studio 2012 with elevated priviliges i.e. as local administrator: a perfect example of a catch22). I suspect that even though the target Web Application’s Application Pool’s identity differs from the Farm Account, there are still some Web Services running (e.g. the User Profile Service) under the Farm Account and this means that you’ll be using the System Account (= Current Application Pool’s Identity) afterall.

The User Profile Synchronization Service requires SQL Server’s full version and it doesn’t seem to fancy named instances either.

Processes like NodeRunner.Exe are eating away my memory like biscuits. As it turns out, these are all search host control related services that on a development machine can be told to back off a little.

So here are my steps and pointers:

Create a new Hyper-V virtual box and install Windows Server 2008 R2 with SP1 (of course you can opt for Server 2012, but let’s keep changes to a minimum for now).

Log on to the new Windows Server 2008 R2 SP1 VM as local administrator.

Install SQL Server 2008 R2 with SP1 (configure the SQL Service Account to run all SQL related services). For the User Profile Synchronization Service to start properly, it’s vital that you install the full version and not SQL Server Express. Also avoid creating a named instance. Alternatively, you can opt to create an alias.

Run SharePoint’s 2013 prerequisiteinstaller.exe (and make sure it continues running when it optionally reboots your server)

Install SharePoint 2013.

Configure SharePoint 2013 using the wizard (configure FUTURAMA\svcacc_spfarm as the Farm Account) and create the SharePoint_Config database on the default SQL instance i.e. not on a named instance or else you might run into trouble later when starting the User Profile Synchronization Service.

Using the Farm Wizard (available from the Central Administration) create a Managed Account for FUTURAMA\svcacc_spsvc and mark a number of Service Applications for Installation (here’s my selection: App Management Service, Business Data Connectivity Service, Managed Metadata Service, Search Service Application, Secure Store Service, State Service, Usage and Health Data Collection, User Profile Service Application and User Profile Service Application).

As last step, let the wizard create a Site Collection so you have default root website. Since it’s a development box, you naturally pick the Developer Site template for the Site Collection’s root website.

Still in Central Administration create an additional Managed Account (Central Administration > Security > Manage security accounts) for FUTURAMA\svcacc_appsvc and change the Application Pool Identity for the default Web Application (I personally like the Web Application to run under a different account as SharePoint Web Services, but it’s a matter of taste).

At this point you’ll need to adjust the memory claim of App Fabric’s Distributed Cache Service. First verify whether the service was started at all (Central Administration > Systems settings > Manage services on server > Distributed Cache). Start PowerShell and make sure you add SharePoint’s cmdlets (Add-PsSnapin > microsoft.sharepoint.powershell + Enter). First verify that the Distributed Cache is UP by typing:

Ps, App Fabric stores its configuration like provider and connectionString variables in the registry here: HKLM>Software>Microsoft>AppFabric>V1.0 and those variables are set when you run Add-SPDistributedCacheServiceInstance as a PowerShell cmdlet.

Now update all the web.config’s of all SharePoint services to avoid them demanding 5% of memory, which on a box with only 6 GB simply is not around. If you don’t do this, none of the services can be activated. To achieve this you need to update the web.config files of all services in “C:\Program Files\Microsoft Office Servers\15.0\WebServices” as well as in “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\WebServices” (or similar folders if you have decided to spread the installation over multiple drives). Simply add the following line “<serviceHostingEnvironment minFreeMemoryPercentageToActivateService=”0″ />” immediately below “<system.serviceModel>” e.g.:

Before you can start the User Profile Synchronization Service you need to make the Farm Account a local administrator. Unfortunately, this group is no longer visibly available on a Windows server that was previously upgraded to Domain Controller. Therefore launch the command prompt as Administrator (right mouse click Command Prompt > Run as Administrator) and type:

net localgroup administrators /add FUTURAMA\svcacc_spfarm

In addition you may find that the NetBios name of your domain isn’t the same as the fully qualified domain name. If that’s the case (or if you just want to be sure) run the following PowerShell commands:

Before starting the service you need to verify whether the Farm Account has permissions to Replicate Directory Changes: http://technet.microsoft.com/en-us/library/hh296982.aspx (also read through the other 3 recommendations – normally they wouldn’t apply, but as the saying goes: Better be safe than sorry).

Ps, If you let SharePoint’s Farm Configuration Wizard configure a default Site Collection, you may find that a MySite host was already prepared for you, e.g.:MySite host: /my (explicit managed path),MySites path: /my/personal (implicit managed path).Otherwise, this is the time to configure MySites and make a (mental) note of the configuration (because you’ll need it later to configure the User Profile Synchronization Service Application).

Finally you can start the User Profile Synchronization Service (Central Administration > Systems settings > Manage services on server > User Profile Synchronization Service). This process may run for up to ten minutes. To make sure nothing goes wrong you can open the current ULS log (HIVE 15 > LOGS) and keep refreshing/reading it as were it a very exciting novell. If you followed these instructions, you shouldn’t see (m)any errors related to the provisioning of the User Profile Synchronization Application.

Also, if you want to see how synchronization was handled by Fore Front Identiy Manager (FIM) you may want to start the Synchronization Service Manager UI that you’ll find here: C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell\miisclient.exe

If you’re lucky, the service has started. According to the documentation you can now remove the Farm Account again from the local administrators group. I must confess that I haven’t done this so far. It’s a development environment after all.

To free up some memory you can now reduce the SharePoint Search Host Controller from consuming unlimited memory resources. If you don’t execute this step (at this time) you might find that a couple of NodeRunner processes consume endless amounts of memory. First set off the following PowerShell command:

Set-SPEnterpriseSearchSerivce -PerformanceLevel Reduced

Then update C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config and set memoryLimitMegabytes to anything greater than 0 (=default):

<nodeRunnerSettings memoryLimitMegabytes="50" />

Conclusion: Life for a SharePoint developer just has grown a bit more complicated, surely if you used to be a lazy guy like me and simply used the local administrator account on your undersized development machine as Farm Account!