blue screen of death when accessing y:

Hi all,

I've seen some threads about this before, but all the fixes mentioned doesnt work for us, so here I go:

We recently did a clean install of 6.5 SP2 on a W2K3 SP1 (R2) server and everything seemed fine. We did have some issues with Norton, so ended up installing the server in the following order:
Windows 2003 SP1 (R1)
TS 6.5
TS SP2
OD 6.0.2 Base
OD 6.0.2 Admin
OD 6.0.2 SP1
Norton antivirus

We did several GUI customisation thingys and tested using the fresh and empty backingstore, and everything seemed fine.

We then copied across our old 5.5 backingstore and activated it to perform an iwmigrate on it (as described in KA 55358).
Now **** has broken loose.

We managed to do a iwmigrate for a single branch as a test, but got loads of "Permission denied" errors, and all the files it copied to the new backing store has all the ext attr and properties right, but are 0 bytes large.

When trying to look at the permissions or properties of any files on the Y:\ we immediatly get the blue screen of death and the server reboots itself.
When trying to preview any files through the TS GUI, we are denied access even though the Default Web Site is set up with the iwmount and anonymous access enabled.

We have disabled the virus scanning of y:, but to no avail.

Our server people logged a case with Microsoft who came back saying:
"Probably caused by : iwfsd.sys ( iwfsd+117a7 )"

The only other weird thing is that in order to run iwmigrate we had to create a user named Administrator. We have renamed our built-in Admin account, but IW has hardcoded the username "Administrator" in the iwmigrate.exe

Does anyone have any idea of what goes wrong here?

Find more posts tagged with

Comments

BNicky

I did experience the same thing.

Before installing you need to make sure all services of Symantec are disabled and stop.
Aslo the Norton email module cause problem so we no longer install it on our server.
Another issue was IIS 6.0, if the default web is rename or path modified, Teamsite does not get configure properly because it is hardcooded in the TSpostreboot.ipl

Adam Stoller

I did experience the same thing.

Before installing you need to make sure all services of Symantec are disabled and stop.
Aslo the Norton email module cause problem so we no longer install it on our server.
Another issue was IIS 6.0, if the default web is rename or path modified, Teamsite does not get configure properly because it is hardcooded in the TSpostreboot.ipl

Note: If you are planning to install 6.5 and then 6.5SP2 - and you don't reboot between the two installations - the tspostreboot.pl script will not work because it looks for the license information in the iw.cfg file as opposed to the TS.lic file - in cases like this you'll have to do the TS-to-IIS configuration stuff manually (on Windows) - I believe the steps include:

I may have missed something in there, but I believe that's pretty much all of the steps.

Cathrine

Hi,

As I said in my posting, we did not even install the Symantec products until after the TS install. We also made sure that when we did install it, it was without the email services.
The IIS got configured like it should, and TeamSite was working perfectly before we did the iw-migrate with the old backing store. I have now re-instated the empty backing store TS created during the install, and everything is working fine again. I've got a top-tuned server performing perfectly, just without any data!

I'm leaning towards the iwmigrate command having messed things up:

We renamed our built-in administrator account before installing TS (company naming conventions), and installed everything using this account, which seems to work fine. However, IW informed us that iwmigrate wont work unless there is a user named Administrator, with administrative rights on the server, so we created such a user and ran iw-migrate with it.
That’s when the blue screens started.
Microsoft identified \FileSystem\iwfsd as the culprit, and we currently have a support case open with IW. The funny thing is that in the debug-logs from MS, there is a mention of the path of the very branch we tested the iwmigrate on:
Object: 887f41c8 Type: (8d57e900) File
ObjectHeader: 887f41b0
HandleCount: 0 PointerCount: 1
Directory Object: 00000000 Name: \default\main\boc\global\external\bocdotcom\EDITION {InterwovenPseudoVCB}

Coincidence? I THINK NOT!

Could it be that because we ran iw-migrate with a user that was only a member of the Administrators group, and not the actual local Administrator, iwmigrate corrupted the backingstore we tried to migrate? I’m clutching at straws, I know….

Adam Stoller

Hi,

As I said in my posting, we did not even install the Symantec products until after the TS install. We also made sure that when we did install it, it was without the email services.
The IIS got configured like it should, and TeamSite was working perfectly before we did the iw-migrate with the old backing store. I have now re-instated the empty backing store TS created during the install, and everything is working fine again. I've got a top-tuned server performing perfectly, just without any data!

I'm leaning towards the iwmigrate command having messed things up:

We renamed our built-in administrator account before installing TS (company naming conventions), and installed everything using this account, which seems to work fine. However, IW informed us that iwmigrate wont work unless there is a user named Administrator, with administrative rights on the server, so we created such a user and ran iw-migrate with it.
That’s when the blue screens started.
Microsoft identified \FileSystem\iwfsd as the culprit, and we currently have a support case open with IW. The funny thing is that in the debug-logs from MS, there is a mention of the path of the very branch we tested the iwmigrate on:
Object: 887f41c8 Type: (8d57e900) File
ObjectHeader: 887f41b0
HandleCount: 0 PointerCount: 1
Directory Object: 00000000 Name: \default\main\boc\global\external\bocdotcom\EDITION {InterwovenPseudoVCB}

Coincidence? I THINK NOT!

Could it be that because we ran iw-migrate with a user that was only a member of the Administrators group, and not the actual local Administrator, iwmigrate corrupted the backingstore we tried to migrate? I’m clutching at straws, I know….

Anytime you run into issues with the backing store - your first step should be to open a case with Support.

That being said - did you run an iwfsck on the "old" backing store before you tried doing the iwmigrate of it?
Did you have the "old" backing store as "active" and the target backing store as "inactive" before trying to do the iwmigrate?
There are probably a number of other questions to ask / logfiles and program output to look through - but you really should be throwing all this to IWOV Support.

Cathrine

Yepp, support case duly opened, and I have thrown as many log-files at it as I can.
But there is always the chance someone here with a slightly better response-time than IW support had been through the same and could give me a solution. (Nothing like a quick fix!)

But to answer your question
We did not run iwfsck on it. Obviously we should.
We did have the old bs as active, and the targeting one was created in the process, so that was definitly not active.

We've been seeing errors related to the iwfsd.sys, but I've gone through the install log and it was definitly updated correctly during the SP2 install, so it should deal with all the Windows SP1 incompatibilities. However, all the symptoms we're getting makes it seems like the SP2 isn't there...
If IW support comes back to me, I'll update this thread, because at this point I have no clue where to look next.

Cathrine

Another thing that just struck me: iwmigrate shouldnt be changing anything on the backing store it's migrating FROM, should it?

The "old" (5.5) backing store was working fine on the TS 6.5 box until we iwmigrated and created a new bs with a branch from the old one. After that, both of those two backing stores caused errors.

It was only when reverting back to the default store created on install that the server started behaving again.

Adam Stoller

Another thing that just struck me: iwmigrate shouldnt be changing anything on the backing store it's migrating FROM, should it?

The "old" (5.5) backing store was working fine on the TS 6.5 box until we iwmigrated and created a new bs with a branch from the old one. After that, both of those two backing stores caused errors.

It was only when reverting back to the default store created on install that the server started behaving again.

I'm not sure what you're saying here - but anytime you take a 5.5 backing store and process it with TS 6.x - that backing store is no longer a 5.5 backing store (i.e. it gets modified in a non-backwards-compatible way).

If you did that, and now decided you'd rather do an iwmigrate instead of letting TS "convert" it transparently (Support initially recommended being able to let TS handle it, but now they apparently recommend against that and suggest using iwmigrate) - then you need to start with a "good" copy of the actual 5.5 backing store - not the one that TS6 already modified.

In either case - you should definitely run iwfsck on the "source" backing store before attempting to run iwmigrate from it.

Cathrine

This is basically the heart of my problems, because I'd happily let TS deal with it and not do the pesky iwconvert, but as you said: the message we got from IW was that we should do it, and that in future, it's likely to show up on recommendations from IW support anyway, and so we'd rather do it now before we go live with this new server since they told us the command could take over a week to run(!) and we dont want that kind of down-time for our users.

However, what they sent us was a knowledge article (55358) describing the scenario we are in, and it says:

"take a copy of the backingstore from 5.5 [..} configure TeamSite to use it by placing it in the path of the default iw-store location on the TeamSite 6.5 system"
Then it says to run iwmigrate to create a new store:

iwmigrate -m Y:/default -o P:\iw-store\new -b \default\main -g > migration_log.txt 2>&1

And then configure TS 6.5 to use this new store.

So everything is happening on the new TS 6.5 server. The article is dated 25 Apr 06, so it's fairly new.

I know iwmigrate is also used to move stores between servers, but we are basically just following the IW instructions, besides, if we were to run iwmigrate from our old Production server to the new one, we'd be looking at one weeks down-time again, arent we?

13adam13

However, what they sent us was a knowledge article (55358) describing the scenario we are in, and it says:
"take a copy of the backingstore from 5.5 [..} configure TeamSite to use it by placing it in the path of the default iw-store location on the TeamSite 6.5 system"
Then it says to run iwmigrate to create a new store:

It is great how support can make a change like this but not notify any of the people who did it the other way.
When you start up the old store on the new server and run the iwmigrate, the person that is running the iwmigrate command has to have access to ALL branches/workareas on the old store. This might mean that you need to use iwidmap to remap the users once the store is brought over. The permission denied errors are corrupting your backing store.

if we were to run iwmigrate from our old Production server to the new one, we'd be looking at one weeks down-time again, arent we?

You can run the migrate without freezing the old system, which means there isn't downtime at this point. Then, once complete, you should restrict access to the system while you update the migration to get any additional editions and changes in the workareas, and then give users access to the new system. This strategy allows for minimal down time to the users, and will give you a good data set for testing just before running the final migration.

Adam Stoller

This is basically the heart of my problems, because I'd happily let TS deal with it and not do the pesky iwconvert, but as you said: the message we got from IW was that we should do it, and that in future, it's likely to show up on recommendations from IW support anyway, and so we'd rather do it now before we go live with this new server since they told us the command could take over a week to run(!) and we dont want that kind of down-time for our users.

However, what they sent us was a knowledge article (55358) describing the scenario we are in, and it says:

"take a copy of the backingstore from 5.5 [..} configure TeamSite to use it by placing it in the path of the default iw-store location on the TeamSite 6.5 system"
Then it says to run iwmigrate to create a new store:

iwmigrate -m Y:/default -o P:\iw-store\new -b \default\main -g > migration_log.txt 2>&1

And then configure TS 6.5 to use this new store.

So everything is happening on the new TS 6.5 server. The article is dated 25 Apr 06, so it's fairly new.

I know iwmigrate is also used to move stores between servers, but we are basically just following the IW instructions, besides, if we were to run iwmigrate from our old Production server to the new one, we'd be looking at one weeks down-time again, arent we?

Hmm - I guess that's the way to do it - though it seems kind of strange that one would migrate the 6.5 store to the 6.5 store, perhaps the migration itself is supposed to clean up aspects of the conversion that the iwserver process couldn't do itself?

I'd suggest running iwfsck on the "old" store before doing the migration though - because if there are problems with the "old" store, the migration might not be that successful.

Also - with regard to access rights after the migration and such - if the "old" store is from a different physical server, you're going to need to use iwidmap to map old local disk accounts and groups to new local disk accounts and groups (there's a KB on this too - somewhere).

None of this, however, explains the BSOD - that is usually some incompatibility between the TS server and the OS - again, Support is probably the best avenue to use for this kind of problem but making sure that the TS versions (with SP and patches as appropriate) is listed as being compatible with the OS (with SP and patches as appropriate) is usually the first step - this info is generally documented in the Release Notes - if you have a TS-SP applied make sure to look at the SP's Release Notes not the base-level Release Notes.