Web application installation path

As you probably know, by default, WSS Web applications are physically created in the 'C:\Inetpub\wwwroot\wss\VirtualDirectories'-directory. This directory is used as default path in one of the fields in the 'Create a new Web application' form.

When you want to place the Web application in an other virtual-directory you need to change this field before creating the Web application. If you don’t, you need to recreate the Web application again.



Windows SharePoint Services 3.0 derives the directory information from the Web server registry setting at 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\PathWWWRoot', this path is subsequently appended with '\wss\VirtualDirectories'. To ensure Web applications are installed on the proper disk volume, modify the Registry values on your Web front-end computers to reference the desired path.

The Registry values can be modified either prior to or after Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007 has been installed. However, any pre-existing Web applications will not be changed (as discussed early in the post). Here’s what you have to do to change the Registry Values.

Configure the WWWRoot Default Path (Windows Server 2003)

1. Click Start, and then select Run…
2. In the Open field enter Regedit and click OK.
3. Locate the 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp' key and modify the PathWWWRoot Value data to 'D:\Inetpub\vroots'.
4. Locate the 'HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ContentIndex\Catalogs\Web key' and modify the Location Value data to 'D:\inetpub'.
5. Locate the 'HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Control\ContentIndex\Catalogs\Web key' and modify the Location Value data to 'D:\inetpub'.
6. Locate the 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex\Catalogs\Web' key and modify the Location Value data to 'D:\inetpub'.
7. Repeat steps 1 through 6 on each Web front-end and application server.

Some of the Registry keys in the steps above may not be available on all Web servers depending on configuration and Operating System versions. Always back-up the Registry before modifying any Registry settings.

Considerations

Some software engineers may say:

A Microsoft Internet Information Services best practice is to avoid using the default path ('C:\inetpub\wwwroot') and moving Web content to a non-system directory. By configuring the WWWRoot default path it provides a safeguard for oversight and promotes consistency across Web servers.
Source: http://sharepointdata.blogspot.com/2009/01/change-default-virtual-directory-in.html.

So best practice is to create a folder in the 'C:\Inetpub\wwwroot\wss\' that is easy to map to the web application and then leave the folder as is.
Source: http://stackoverflow.com/questions/143162

i Note
Please take appropriate considerations when you consider changing the virtual-directory path.

Windows cannot bind to XXX domain. (Invalid Credentials) - Event ID: 1006 and 1030

Problem
You probably noticed that I’m checking through the event logs of our servers. I found another issue today! This one is related to a Windows Server issue.

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1006
User: admin.XXX
Description:
Windows cannot bind to XXX domain. (Invalid Credentials). Group Policy processing aborted.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

and

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
User: admin.XXX
Description:
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Solution
I browsed a couple of Google results and found an interesting post.

5 Jan 2006 2:43 PM scole
I am not positive, but I think there was a problem with someone remoting into the server and never logging out. Then their password changed. I was able to go in and kill their connection (which had been open for 5 months). Hope this helps. Source

I looked into the Terminal Services Manager and found a user that was "idle" for a while. I told the manager to logout the user. After a few hours I checked the event log again and noticed that the errors were no longer occurring.

Guess this solved the problem! :-)