Tuesday, October 2, 2012

Sharepoint 2010 and IIS on a new drive

For my SharePoint implementation, we had created an OOB web server, and installed SharePoint as a Web Front End (WFE).  However, we wanted to keep the OS drive minimal and separate (for security purposes).  As such, we created a second drive, and the task seemed simple enough - move IIS and SharePoint to the new drive.  Doing so caused quite a few headaches, and it also broke my custom SharePoint Designer Masterpages.  Actually, in the end, it is simple, but as they say, life is not the destination, but the journey.  As you can guess, this post is the summation of that journey.

So how do I do this?

Simply put:
  1. Create your new IIS location
  2. Install SharePoint
    • When given the option, choose to install to your new "inetpub" location.
  3. Move all your existing webs to new location (including SharePoint)
  4. Update IIS to recognize new webroot for SharePoint web and SharePoint Central Admin

So why was this so difficult that it required a blog post?


Well, if one were to follow the order of operations listed above, then all goes well.  Alas, I was unaware of the order of operations, and instead had done something similar to the following:
  • Install SharePoint
  • Created my new IIS location
  • Attempted to move SharePoint to new IIS location
    • Angered the SharePoint gods (unknowingly)
  • Successfully Browsed SharePoint site - and rejoiced!
  • Discovered my custom SharePoint design is now broken
    • sobbed and repented
  • Un-installed SharePoint
  • Re-Installed SharePoint, and took notice of the handy-dandy tab to choose my installation location
  • Updated IIS to recognize the new location of my webroots
  • Broke SharePoint Central Admin
    • Freaked out
  • Updated references on MasterPage to recognize SharePoint location
  • Fixed Central Admin
As you can see, my method was not very concise.  You're welcome to try it.. but if you want to move IIS to a new location, these are the steps to run IIS and install SharePoint from a non-default drive point.

Installing SharePoint to a non-default location.


As mentioned above, this is actually, insanely simple.  During installation, choose the File Location tab when choosing Complete or Stand-alone installation types.  Choose your drive location and continue.  This will NOT install to a different IIS directory off of your "C" drive, this will just install certain application files in a separate directory.

Moving IIS to a new drive location

On your web server, create your new directory where you want to host IIS from. Then, download the MoveIIS7Root.zip file from Thomas Dehl's blog post:  http://blogs.iis.net/thomad/archive/2008/02/10/moving-the-iis7-inetpub-directory-to-a-different-drive.aspx.  Edit the bat file to indicate the location of you new IIS Root, and execute the statements.

Moving SharePoint's webroot to the new IIS location

With IIS now on it's new location, you need to ensure that the IIS references to SharePoint's webroot are accurate.  Open up the SharePoint PowerShell Admin tool and use the following commands (thank you to sbommana for the guidance on this - http://sbommana.wordpress.com/2011/05/11/move_inetpub_on_sharepoint_wfe/):
#Create a web application object
#Example: $SPSite = new-object Microsoft.SharePoint.SPSite("
http://intranet.foo.com")
$SPSite = new-object Microsoft.SharePoint.SPSite("URL")
$WebApp = $SPSite.WebApplication

#Change SPUrlZone if not in default zone
$IISSettings = $WebApp.IisSettings[[Microsoft.SharePoint.Administration.SPUrlZone]::Default]

#Point to your new directory
#Example: $IISSettings.Path = "E:\inetpub\wwwroot\wss\VirtualDirectories\<SiteID>"
$IISSettings.Path = "<Your IIS Path Here>\wss\VirtualDirectories\<SiteID>"

#Update Web Application
$WebApp.Update()
$SPSite.Dispose()


Restart IIS, ensure that your SharePoint web is responding.  Then, try your SharePoint Central Admin site to ensure that it is responding.  If it isn't, check your server event logs for clues.  In most cases, you may find the item "Safe mode did not start successfully".  This issue could be because of service permissions.. but chances are in this case, because you just performed open heart surgery on SharePoint.  To resolve, unprovision and re-provision your central admin site by using the following commands using the command prompt (and dont forget to run as admin!):

psconfig.exe -cmd adminvs -unprovision
psconfig.exe -cmd adminvs -provision -port <port number>

What about the SharePoint Designer issue?

Here, my MasterPages were edited via SharePoint Designer.  Once I performed the above steps, my SharePoint site was responding, but I couldn't edit or deploy any of my custom MasterPages.  When I was viewing them within SharePoint designer, none of the controls would even load within the designer. My assumption here is that it is also related to the aforementioned open heart surgery on SharePoint.  Alas, once again the fix was relatively simple.  I created a new site in SharePoint, opened up the default MasterPage in SharePoint Designer for that new site, and copied over the "Import Namespace" and "Register Tagprefix" page directives to my currently broken MasterPage.  I saved, closed, and re-opened the page in the designer, and SharePoint designer was happy once again.

No comments:

Post a Comment