Visualize yourself the scenario were you are about to set up a SharePoint environment containing a lot of Web Applications and that some of them needs to be extended both two and three times. Add to that, that you need to set it up in a Test, QA and a production environment and in the same way have a good recovery plan for setting them up again in case of a disaster.

In two earlier posts I have written about how to create a Web Application and how to extend a Web Applicationusing PowerShell. Now it’s time to combine the two into one script where we use a input file as source. In this case I decided to use Excel, so it’s easy to fill in all info on your Web Applications in an Excel file. By using a macro you can then by pushing a button in Excel generate a xml-config and that’s the one to use as input for your PowerShell script.

First, let me introduce the Config Generator. This is an excel file where you fill in the info on the Web Applications that you want to set up. Below is a list of all the settings you fill in, in the Excel sheet. One Web Application or extend of Web Application per row.

As you can see you have a couple of fields related to the IIS Application Pool. What the script does is that, if you have filled in the WebAppUsername the Application Pool will be created with the new credentials. If you leave the WebAppUsername blank it assumes that the Application Pool exist and connects the site to that Application Pool.

You will also find columns to insert Site Collection information. This info will be put into the config file as well and used for creating the root Site Collection of your new Web Application. The following settings are available:

When you have filled in the info on all your Web Applications just push the Generate Config File button and Excel will generate a config.xml file in the same folder as the Excel file is located in.

What you then need to do is to copy the config.xml to the server along with the CreateWebApps.ps1 file.

Open up the PowerShell command shell, include the file CreateWebApps.ps1 file by typing:

. ./CreateWebApps.ps1

Then you call the function by typing:

SP-WebAppBuilder -ConfigPath [path]\config.xml

This will now generate all your Web Applications as you have specified in the Excel-file so go grab yourself some coffee and let the script handle the rest.

The above example is an teaser of what will be covered in the coming book SharePoint and PowerShell – In real life that I together with Niklas Goude is writing. The code can be found in the download section.

I sometimes use Fiddler (which is a great tool by the way) when inspect the HTTP traffic, but without a custom HTTP Header it makes the hole process much more difficult.

Once again, I’m not much for repetitive tasks and in this case I had a lot of WFE’s and web applications. Therefore I put together a small script that enumerates and adds ServerName: [Servername] as custom HTTP header to all your sites on the server. You find it in my download section under IIS. And please don’t hang me for not making a beautiful script, It was a quick and dirty one and if you want to shape it up please feel free to do so.

The Problem was that I were about to update a Global Site Template. The template was sent to me from the customer and should be implemented in one of our staging environments to be tested and then finally published in the production environment.

Since this was a new version of an already existing template I started with deleting the template with stsadm (stsadm -o deletetemplate) and then I used the stsadm again to add the template (stsadm -o addtemplate). But when using the addtemplate I get:

Web template with file MyTemplateName.stp already exists

I did a enumtemplates to see if the template I deleted really had been deleted and it had. I tried to delete it again but then but got:

Could not find web template MyTeamplateName.stp

I then tried to add the template with a new name and this worked fine but when I created a new Site Collection based on the newly added template, I received yet another error message:

The template you have chosen is invalid or cannot be found.

I jumped to the conclusion a bit too fast and thought that this was related to each other. I was wrong. It turned out that this was a two folded problem and I have only found a solution to the last part.
I found out with help from a simple yet excellent Codeplex tool named STP Inspector that allows you to examine your stp file and I then found out that we did not have the same solutions (or at least same versions of solutions) in our different staging environments. The template was generated from a environment with one newer solution and therefore had Feature that was not installed on the environment were I tried to add the new template to.
To find out what feature it was I used another great tool from Codeplex, SharePoint Inspector. Both tools are very useful and I totally recommend putting them into you “toolbox” when working and troubleshooting SharePoint problems.

So what happened to the first problem? Well I have not solved this and neither have I got any response from the brilliant people on msdn forums so I guess this is a quite unique problem I have ran in to. For now I have down prioritized it but if you have a good suggestion I would much appreciate it, just leave a comment here or on the forum thread found here: http://social.msdn.microsoft.com/Forums/en-US/sharepointadmin/thread/cff841dd-00b2-4706-9a71-6f112eeef2ab

There are a lot of things that can cause problems with the explorer and therefore comes here a troubleshooting guide.

First of all let’s just briefly explain how this Explorer View works. The Explorer View is a built in SharePoint View and is available out of the box on both WSS and Moss. What happens when you switch to the View is that the content of the Document Library is displayed as if you are using an Explorer Window on your computer. Depending on what Browser you use the window opens up as new Explorer Window or integrated in the browser itself.

In the background the protocol that is used is WebDav. WebDav is the updated version of the old FrontPage RPC protocol (FPRPC). When you try to open a Document Library in the Explorer View WebDav tries to connect to the SharePoint Library and if it for some reason fails, it has a fallback function and tries to connect via the FPRPC.
There are two easy ways to see if your connection is done using WebDav or FPRPC. When connected to the Document Library, look at the path displayed in the Explorer Window. If you see a path looking like a mapped drive starting with two back slash ” \\” then your connection is done with WebDav, if you instead have http:// in the path then it’s a FPRPC connection you have. You can also determine it by right click in the Explorer Window and look at the options that are given. If it’s a limited menu appearing then you have the FPRPC.

If the menu looks just like when you working with files locally on your computer then you are using WebDav.

Since WebDav is a much better protocol you should aim for having this protocol working instead of the older FPRPC. Earlier (Windows XP and backwards) WebDav were only possible through port 80, but with Windows Vista there were an updated version to the WebDav Client on Windows machines and it now allows https. If you are not running Windows Vista I recommend you to download these and install this:  http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=17c36612-632e-4c04-9382-987622ed1d64

A common misunderstanding about WebDav and SharePoint is that you need to allow WebDav in the Web server extension in IIS to get the Explorer view to work. It’s true that it uses WebDav but SharePoint handles this in itself and therefore it actually doesn’t matter if you have it enabled or not, at least not for the Explorer View. If you are using other components or for instance SharePoint Designer then you need to enable it and by default its disabled.

If you have made sure that you have the latest WebDav client and you still for some reason can’t access or use the Explorer view properly you should start with deleting temp files located in your nethood folder located in:

Windows XP:
 c:\documents and settings\[Username]\nethood

Windows Vista
c:\users\[Username]\nethood

And you should also delete the cache files located in:

Windows XP
c:\documents and settings\[Username]\application data\microsoft\web server extensions\cache

Windows Vista
C:\Users\[Username]\AppData\Roaming\Microsoft\Web Server Extensions\Cache

This should especially be done if you have connected to the Document Library via FPRPC earlier and now want to make it work with WebDav. Note that after deleting this you should reboot your client.

In one of my recent assignments we had a big problem with the Explorer view not working in some of our environments and in some it worked like a charm. We also had different results depending on client. So finally we opened up a case at Microsoft and it turned out that there is a bug in Windows XP (that they don’t intend to fix since XP is now in a Extended Support Phase) were the Webclient and mrxdav services is started in the wrong order.
To see if this is the problem start a commander and type:

net stop webclient,
net stop mrxdav
net start webclient

This is something that could be incorporated in the logon script to ensure proper functionality of the client. There is unfortunately no known KB for this which is a pity since there are probably more then one that has encountered this problem.

If this still doesn’t work you should start looking in to Proxy server, Firewalls or Load Balancing server. To test and troubleshoot network problems related to the Explorer view is a whole other story but there are a couple of good tools I recommend.

Fiddler is a free tool for logging all your http or https traffic and then afterwards you can analyse it you find it here: http://www.fiddler2.com/fiddler2/

NetMon is a Microsoft tool for analysing traffic and can be used both on your client and on your server. Found here: http://www.microsoft.com/downloads/details.aspx?familyid=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&displaylang=en

If you want to learn more the Explorer View and the WebDav protocol you should defenately read the Microsoft Whitepaper named Understanding and Troubleshoot SharePoint Explorer. It’s a couple of years old but much of it still applies.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c523ac7a-5724-48be-b973-641e805588f4

First out is a migration tool called Xplica. The tool helps you migrate documents from on SharePoint 2003 or SharePoint w3 environment to another WSS or Moss environment. It is mainly used when moving from an old unstructured SharePoint 2003 environment to a brand new Moss setup. The tool needs to be purchased but the price very reasonable.

For being a small and simple tool it has a lot of different settings and features. It can maintain existing metadata such as creation date and last modified by, but you can also create a reference file with your new metadata values so that you can move and add metadata at the same time. Other options you have is to schedule the migration (so it can be done by night), keep old versions and remove stinky folder structures so that they end up in a plain list, ready to create views on.

I used this tool quite recently and for smaller migrations I like it and can recommend it. I also initially had some problems (that was security based) so I contacted their support and got a quick and good answer that helped me.

Below are a couple of screenshots.