Move your SharePoint IIS sites from the systemdrive(C:)

Move your SharePoint IIS sites from the systemdrive(C:)
or avoid putting them there in the first Place.


Do you see the lion that is totally in the wrong Place…or is it the Jeeps that are…?

Deal fellow SharePointlovers!

This time, I’ll try to show you how to avoid the messed up situation most SharePoint installations are in, with everything on the systemdrive, or C:
Now, us people have over time been better and better at one thing, we understand that the logfiles should not be located on the systemdrive, so we have learned over time to move the ULS log and the Usage and Health log from C:, some have even been clever enough to move even the IIS log from C:

But, what do we still always, always, always, find installed on C:?… … …yes, C:\inetpub!

It not very strange though, the developers of Windows Server have made a point out of not giving us an option to install inetpub on a different path, not unless you do an unattended installation or otherwise script or Control your installation. The ‘Add/Remove roles’ wizards in Server 2008, 2008R2 and 2012 all lack this option (for a reason).

BUT! This is intentially, the default inetpub location should and must be in the systemdrive, IIS is considered an operating system Component and has to be there for a number of reasons. At the end you will find a link to a KB article that explains this in more detail. Leave inetpub and its subfolders where it is!

So, why would we want to do this anyway
why move the inetpub and all of its content, or at least the separate site catalogs to a different drive?
– Separation (Performance and Security)
– Compartmentalization (Performance and Security)
Having averything on the same drive is bad for a few reasons, primarily performance and security. Perfomance since the OS is on the C drive and security because if an attacker by some means gets access to a different less secure applications sitecatalog, they also get access to the systemdrive and possible also all other webapplication sitecatalogs. Moving them to other drives, same or different, helps mitigate both possible issues.
I therefore recommend doing this:

Do your regular installation, add the Web Server role and let the inetpub folder end up on C:, like I said, no worries. Whats important for us will not be located there anyway.
Next, edit the registry to make the default location of inetpub be for example D: (unless this is were you will be putting all of your logfiles, then select a third or fourth drive)
Install the SharePoint as you would normally do, Central administration will now end up were you pointed the default location.
Create your Web Applications using the GUI or PowerShell and leave out the path, the IIS sites will be were you wanted them.

So, how do we do this in more detail? A Guide…

Configure the Web Server(s)

1. Configure the default location

On all of your web servers in the farm, and on your Central Administration server(s), edit the registry key that Controls the default location:

Start regedit by, Right clicking in the very lower left corner and you will get a list of actions, click on Run.


Type Regedit and click Ok.


Click Yes in the UAC dialog.


In Registry Editor, we locate the following path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp



Under ‘InetStp’ we have a number of keys.


Locate and Edit the key PathWWWRoot from the default: (%systemdrive%)


to: (D: or where you prefer to locate it, E: F: G: H:…)


There you go! All set, no IIS reset or restarts of any kind required.
Like said before, go on and do this on all servers that will host a webserver (WFE or CA). If you don’t, then you will have an inconsistent setup making Everything very hard to setup and t-shoot.

2. Add SharePoint
After this has been changed on all of you r web servers, you can go ahead and install the SharePoint binaries and configure your farm, The Central Administration site will now be located on the drive you have specified, it will be in the exact same path as it normally would but on a different drive. For example: ‘D:\inetpub\wwwroot\wss\VirtualDirectories\20000\’

Note that the Central Administration UI will now be default suggest a different path:


If you create a new site using PowerShell, it will also by default put it in D: even if you don’t specify any path:

New-SPWebApplication -Name TheVeryFirst -ApplicationPool SharePoint -HostHeader -Port 80 -Url -DatabaseServer blksthl-sql -DatabaseName SP11_Content_TheVeryFirst

As you can see, were done! 🙂


For the logfiles, I’ll make a separate post, they should also be moved, more so even than the sitefolders. Logfiles will fill up the disks, they will slow performance and maybe most importantly, they contain delicate information that you want to keep separated from the OS and IIS.


Guidance for relocation of IIS 7.0 and IIS 7.5 content directories

Configure ULS log and Usage and Health log location

Thanks to:

Mikael Nyström (The Deployment Bunny) – Truesec
Mattias Gutke – CAG


Good Luckl!!


Twitter | Technet Profile | LinkedIn

Anonymous Authentication always on in SharePoint 2013

Hi friends.

Anonymous access is default on in SharePoint 2013, even if you select No?

First, remember, this is all just a reflection made by me and most likely, there is some obvious reason as to why this is, that simply just eludes me at this point. I know that SharePoint does not in itself allow Anonymous access, that has to be configured, but IIS allows it which seems to me like a bad idea.

I noticed this disturbing thing this morning when I created a Quick Web Application in a SharePoint 2013 test farm of mine running on Windows Server 2012. Thing was, I created a web application from the Central Administration GUI and selected all the quickest options, Default Everything but to use an existing Application Pool. This means that we select Windows Authentication, NTLM only and NO Anonymous access.

Let me explain…
On a SharePoint 2013 farm running on Windows Server 2012:
I created a normal Web Application using only the Central Administration GUI. I used port 2013 just to show where it is, then default on all security settings.

Like this:

I seelcted to use an existing Application pool to save time and Resources, but that is not relevant. Ok to create:

Next I checked what was actually done in IIS, from the preview I remebered having some questions on how this was performed…
In IIS 8.0 on Windows Server 2012 it looks like this:

Notice how 4 providers are enabled by SharePoint as default.
Anonymous Authentication
ASP.NET Impersonation
Forms Authentication
Windows Authentication

These are all enabled by default, Windows Authentication has only NTLM configured like we selected in CA. We also get a warning from having Forms Based authentication(redirect) and Windows Based(Challenge) enabled at the same time. IIS does not like this but I have managed to find out that this is ok, given certain circumstanses you need it to be this way.

If we do the same thing on a SHarePoint 2010 farm running on Windows Server 2008R2 and IIS 7.5:

We select to use NTLM and to not allow Anonymous, same as in 2013.

The settings in IIS:

And the list of providers look like this:

Like you can see, SharePoint 2010 only enables ASP.NET Impersonation and Windows Authentication.

If we put the two up side by side, it looks like this:


The question is, does this affect security in any way?
Is it still as secure?
Why not simply disable Anonymous Authentication?

If anyone has any good suggestions or explanations, please submit them as a comment and I will update this post to reflect the facts.


A really good link that explains the inner workings of claims based authentication in SharePoint, valid for 2010 and 2013 alike.
(Thnaks nojanaj for the tip)

Multiple Authentication Methods in SharePoint 2010




Twitter | Technet Profile | LinkedIn