Dave:
As we had discussed, we are dealing with an unknown issue ( I can find
no references to a similar occurrence) I suspect was related to the
installation of the ADSM client then using other functions before
configuring the ADSM client. I assume the client was configured
immediately by the administrator on the machines that did not have a
problem.
Another possibility is that this is file or registry corruption that was
unrelated to any software interaction, it could have been a hard drive
or SCSI adapter problem. If it's the hard drive, the low-level format
via the SCSI adapter utility will probably solve this issue. It would
be a good idea to check out the hardware on this machine, particularly
the motherboard and SCSI adapter, as comprehensively as possible.
As some client and application software has not been extensively tested
against NT 4.0, it is always wise to check with the vendors of such
software to determine if they have any configuration experience or
advice regarding interaction with NT 4.0; it is hard to predict the
behavior of all such software without testing.
Your strategy to recover has been sound, to reiterate our strategy for a
safe migration to NT, it would be to:
1. Make a tested backup of working 3.51 installations before upgrading
2. Stopping all third party services and clients (when feasible) before
upgrading
3. As new software is installed, a backup is made before installation,
then aggressive testing of the software, one component at at time, is
done until stability is assured.
4. Check with software vendors to assure that their components have
been tested, and no problems noted, under NT 4.0.
If I hear anything specific about interoperability issues with ADSM,
I'll be glad to let you know; please forward me any information you have
as well. Thanks, and
Best regards,
Greg Nichols
Microsoft Windows NT Support
>----------
>From: Thomas, Dave[SMTP:dethomas AT mke1.ra.rockwell DOT com]
>Sent: Sunday, October 20, 1996 5:00 PM
>To: Greg Nichols
>Subject: NT 4.0 workstation mystery - case SRX 961017601192
>
>Greg -
>
>After we spoke Friday, I ended up starting over. I formatted the drive
>using the SCSI utility, created 2 FAT partiions for C: and D:,
>reinstalled DOS and Windows 3.11, then reinstalled Windows NT over the to
>of the Win3.11 install. I've re-installed the majority of my working
>software (Visual C++ 1.52, Visual C++ 4.2, Codewright 4.0, MSOffice,
>...) So I'm online.
>
>I wanted to write down the sequence of events which lead to my NT
>Workstation disaster, before this fades into the past. Our LAN has 4 NT
>servers (3.51). I run NETBUIE and TCP/IP but there are a few IPX
>die-hards around.
>
>My original installation of NT 4.0 had....
>
>32 Meg of memory
>1 4Gbyte SCSI drive
> C: was a 2 Gig FAT partition with C:\windows
> D: was a 2 Gig NTFS partition with D:\winnt\system32
>SCSI CDRom
>IOmega ZIP drive
>dual boot between WFW3.11 and NT Workstation 4.0
>
>I was running this configuration for roughly two weeks without
>significant problems. I had the normal admin shares ($C, $D) on the
>drive partitions, and had a repair disk/boot floppy set. I can't recall
>what other shares where present, but I think at least one other share
>existed for C:, and this share was private to my domain user account.
>
>Other users on my LAN have been using ADSM, the IBM backup product,
>without problems. I installed the client, our backup admin guy needed to
>enter my name into a registered user list or something, and needed to
>modify a file with my employee number as part of this.
>
>I'm not completely clear about the exact sequence of events which follow.
>Somehow, when my backup admin left my machine, I had new drive volume
>labels, and at least one share on the D: drive to which "Everyone" had
>full acess. I don't know how this share was created. I noticed this
>several hours later, and tried to make the share private to my domain
>account. I got an error message whose text I don't recall, something
>like "so-and-so is busy, cannot complete operation, Continue?" I punched
>OK, and continued to use the machine. I eventually logged out without
>incident.
>
>At the next login, under 4 accounts (domain/machine, admin/my user
>account) the following behavior occured. The login box took the
>password, cleared the login prompt, and gave me a desktop background
>without any icons or taskbar. During this process, a message box error
>prompt came up: "Cannot open folder. Path is too long" with "Desktop" in
>the title bar of the message box window. However, CTRL-ALT-DEL would
>bring up the logout box, and I could run TaskManager.
>
>I ran the repair disk process here to no avail.
>
>I eventually called Microsoft on our corporate support account and spoke
>to Virginia. We did a bunch of registry hacks, eventually changing my
>shell to WINFILE.EXE and allowing me to launch applications and map
>network drives. However, I could only see the D:\WINNT\ directory tree,
>and was denied access to the rest of the drive. Since the compiler was
>out there, this was a problem. In addition, the file c:pagefile.sys had
>been truncated. I returned this to the previous setting (93meg) but to
>no avail.
>
>It was around this point that we spoke, and I copied in the GRPCONV.EXE
>hot-fix you provided. As you know, this didn't help. In addition, I was
>unable to use the administrative share ($D) for the D: drive; when logged
>into the network server as Admin I received "Access denied" messages when
>I tried to map the drive on my workstation. In addition, if I used an
>application which employed the Open and Browse common dialogs, I received
>a message much like the login gave me: "Cannot open folder. Path is too
>long"
>
>Since I had access to my data files on C: and my usual collection of
>network drives, I was able to copy off my work to the server. I then bit
>the bullet and reformatted the drive and reinstalled everything. I have
>asked my backup admin guy to contact IBM and ask about ADSM, but I'm the
>only user out of a dozen or so that had problems.
>
>So, that's the story. I realize there are some grey areas, and I'm
>unclear on what drive shares existed when and who created them, but
>that's water over the dam. I'm running now, and only had a 100 mail
>messages or so to plough through on Saturday.
>
>
>Thanks for the attempt at saving my original installation. If this case
>gets resolved, will I find out? Our backup admin is supposed to follow
>up with IBM, if I hear anything I'll let you know.
>
>Thanks
>
>
>David
>
------------------------- Original message header:
>MAIL FROM:<gregnic AT MICROSOFT DOT com>
>MAIL FROM:<gregnic AT MICROSOFT DOT com>
>RCPT TO:<dethomas AT mke1.ra.rockwell DOT com>
>DATA
>Received: from INET-03-IMC.itg.microsoft.com (mail3.microsoft.com) by
ns1.mke.ab.com (4.1/SMI-4.1)
> id AA24987; Fri, 25 Oct 96 15:01:59 CDT
>Received: by INET-03-IMC.itg.microsoft.com with SMTP (Microsoft Exchange
Server Internet Mail Connector Version 4.0.994.56)
> id <01BBC274.FF2C5170 AT INET-03-IMC.itg.microsoft DOT com>; Fri, 25
> Oct 1996
13:04:03 -0700
>Message-Id:
<c=US%a=_%p=msft%l=RED-71-MSG-961025200108Z-31598 AT INET-03-IMC.itg.microsoft
DOT com
m>
>From: Greg Nichols <gregnic AT MICROSOFT DOT com>
>To: "'Thomas, Dave'" <dethomas AT mke1.ra.rockwell DOT com>
>Subject: RE: NT 4.0 workstation mystery - case SRX 961017601192
>Date: Fri, 25 Oct 1996 13:01:08 -0700
>X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
4.0.994.56
>Encoding: 143 TEXT
------------------------- End of message header.
=========================================================================
|
