Migrate FrontPage web from IIS6 to IIS7.5

After weeks of try and error, I think luckily I have archived what I wanted. Not 100% but to an acceptable level.

100% is to copy everything. Users would not even notice that it is moved. But that was not possible. I could not figure out how after all. The thing missing is user permission. That, I think I would re-setup manually. At least the admins. Then ask them to deal with their colleagues.

First, I write about the method that did not work for our site after all. I believe that is due to something particular with our site, which I could not figure out. I may have achieved the 100% if I could.

You copy the site to your new 2008 R2 server using msdeploy tool. http://learn.iis.net/page.aspx/427/migrate-a-web-site-from-iis-60-to-iis-7/

You activate (“extend”) FPSE (FrontPage Server Extension) on the copied site.

At this point, you realize that the FP user permission are missing. This is what you should do: http://blogs.msdn.com/b/robert_mcmurray/archive/2009/10/12/migrating-fpse-roles-between-servers.aspx.

In case your site is simple enough, this is the end of the story. You have achieved the 100%. However, with our site, the server health check repair did not work. It ends with an exception, without telling me what it does not like.

Giving up to copy the permission, I uninstall FPSE once then re-extend. Failed too. Stuck...

Here is the workaround that I found. I cannot activate FPSE on the fully copied site. Let us then have an empty FPSE enabled site first, and then pour the actual site data into it.

I created a blank web site, activate FPSE, and finally copy files from the old server with the following command.

msdeploy -verb:sync -source:metakey=lm/w3svc/1551257136 -dest:metakey=lm/w3svc/2,computername=newserver -skip:objectName=dirPath,absolutePath=.+_vti.+ -skip:objectName=metakey,absolutePath=.+vti.+ -skip:objectName=metaKey,absolutePath="fpexedll.dll"

The “-skip” parts are my invention. No documentation found. They are to not to copy FP related stuff. It looks work. All webs are copied, seem working. I can create FP web on them.

No real alternative yet for FrontPage Server Extension

After days of frustrating analysis, my conclusion at the moment is to stay with the now-has-become-a-third-party-product FPSE.

My requirements are:

1. I, the server administrator, do not want to do much. I do not want to be called to intervene each time a web site is to be created. Once I have appointed developer A for admin of web site host/siteA, I do not want to have to intervene for host/siteA/siteA1 etc. Moreover, when he has got a colleague who assumes the same role as him, he could do the necessaries.
2. Operations for developers such as managing the web site permission, deploy their codes, should be straightforward.

With FPSE on a 2003 box, it has been near perfect. Except for one thing. No means that developers can verify if a folder is setup as “application”. They can turn a folder into an application, but cannot verify.

The story started when we start thinking of upgrading our web server, currently IIS6 on 2003 box, to IIS7.5 on 2008 R2. Soon I came to know that FPSE is no more supported. There is one as a third party product, but not from MS. Not yet for IIS7.5 but it is said to become available soon.

What is then the MS’s alternative? None that I can see.

Visual Studio 2010 supports the followings for code deployment.

1. FPSE
2. FTP
3. Network share
4. Web Deploy # Only for Web Application Projects
5. WebDAV # Some say you could, by mapping it as (or like) a network drive.

I do not know if you agree. But to me, 2 and 3 seem going back to the stone age.

4. Web Deploy should be the first choice. It is new so must be better. But some say that converting a web site project to web application is not as straightforward as you may think. In addition, it does not fulfill one of my requirements above. The server administrator has to do whole a lot!!

If I setup the “Application” host/siteA for developer A, he could autonomously do the child application host/siteA/siteA1, by importing the siteA1 application with the IIS7 Remote Administration. (I so far fail to do the same with VS though) But he cannot give the permission to his colleagues by himself. It is understandable. When the server administrator setup an application, he needs to not only configure IIS Manager Permission but folder permission as well, while with FPSE you do all these in one go.

Finally, 5. WebDAV too appears to have the same shortcoming, lacks the permission management delegation capability that we want. It is said “The IIS7.* WebDAV extension module supports per-URL authoring rules, allowing administrators to specify custom WebDAV security settings on a per-URL basis.” But as it reads, it is for (server) administrators only. When you connect to a site or an application, with the IIS7 Remote Administration, you do not have the WebDAV Authoring Rules icon. And to connect to the server (then you have the icon), you need to be the administrator...

And above all, needing to map WebDAV folders for publishing web sites from VS does not sound to me an optimum solution...

CSS delivered as Content-type: application/octet-stream

I do not know if this could ever be any benefit of anybody. It could be just that there is something wrong with our servers…

On our site, sometimes (it appears) CSS files are delivered to clients as Content-type set to application/octet-stream.

The story starts as a few colleagues report pages are displayed ugly without styles on Firefox and Chrome. OK on IE.

I found that the CSS is stored in the browser's cache as application/octet-stream. This is tricky because once you clear the cache and go to the page again, the CSS would be downloaded OK.

There seems nobody having similar issue, or at least reporting to the net. I tried to come up with an own workaround.

I wrote an HttpModule to verify if responses for css files are generated correctly as Content-type: text/css, and correct it if not. It writes into the log file each time it find such a problematic response. By the way, in the course of writing the module and testing it, I found that IE applies styles even if it receives the css file as application/octet-stream. This is why the problem has been reported happening only on Firefox and Chrome. Furthermore, for some css, those that SharePoint generates, you can change the Content-type (to application/octet-stream for the testing) in the MIME type configuration of IIS. However, those of our own creation, those in the /Style library folder, come as text/css, even after the change in the IIS’s MIME section. So it is SharePoint that controls it.

Towards the end of the first day after the module is plugged in, the module reported that it did the Content-type correction. And a lot! We have two Web Front End in a farm. Both connect to one single Content database. Each web server generates those mal formed css responses at different timings.

Each has a IISRESET scheduled job. At different times of a day, obviously. Each generates the problematic responses after the IISRESET and stops doing so when the application pool gets recycled. (it gets recycled when the memory usage reaches the threshold)

Sh*t!! I should have requested pages from the server while the module there was reporting the problem!! I could have verified that my Content-type correction does the trick. No worries. It would come again, I guess…

Post from Windows Live Writer

 

Let us see how it goes…