Windows 2000 Server & Windows 2000 Professional Dual Boot

http://support.microsoft.com/default.aspx?scid=kb;en-us;318447

Please read the KB article posted above. The problem is most likely caused by having the two partitions seen and used by one Operatings System. When you boot up the Server partition and you try to copy to the partition with Professinal on it, there is confusion over the system shares and the NTFS partitions. It will happen to both OS's when they see the other partition. Essentially, the Operating System sees shares and NTFS permissions, that are not its own on its disk drives.

J

Important... the KB describes the problem, but I want to make sure you know that it cannot help you. The KB helps when this problem occurs on a single OS, not the dual boot system you have. You probably want to try to reinstall both systems using FAT permissions and then make sure not to share any drives.


J

jdeclue:

Thanks for your quick response.  I was considering to use FAT32, thinking it was an NTFS security issue.  Based on your response and suggestions, I will try this but...  I would need to have the drives shared within their environments.  

Example:  This particular machine will primarily boot to Windows 2000 Professional 100% of the time unless the MAIN Server crashes.  Windows 2000 Server will reside on the C:<PARTITION> and Windows 2000 Professional will reside on the D:<PARTITION> of the pc backup solution.

My additional question is...  Using the PC's normal "100%" operating state "Windows 2000 Professional.", if I was to share the "D" Windows 2000 Professional Drive, will I continue to have the same problems if both partitions were formatted in FAT32?  In the event the MAIN server crashed, then I would need to boot to the "C" partition using Windows 2000 Server with its "C" drive shared.

I hope my explanation was clear.

Thanks,

Joe

Sorry, but jdeclue's explanation is definitely not the issue here.
The two OSs couldn't care less about shares on the respective other partition; they simply don't see them. Shares are defined in the OS's registry, in HKLM\System\CurrentControlSet\Services\Lanmanserver\Shares. A share of an inactive OS on another permission will not be seen by the active OS, so there's absolutely no collision there. As far as the active OS is concerned, the other partition consists just of some folders and files.
NTFS isn't the problem here, either. Default permissions in Windows include only generic groups; these have well known SIDs, which are independent of the machine's SID; so permissions for the local Administrators group are available on either OS. The only issue would be if permissions to a folder on the "inactive" partition have been restricted to only(!) custom created local(!) groups or users; but the only thing this would lead to is an "Access denied" message, not problems with services.exe.
Independent of that, another indication that this explanation is incorrect would be that this happens as well when copying from the CDROM.
You might check your registry for rogue share entries anyway as described in the article; these entries occur if you delete a shared folder without removing the share first.
If the problem happens mostly during copying from CD, then you might have hardware or driver issues, but it has nothing at all to do with the fact that both partitions are NTFS.
Is there anything in the event log?

Well, that's kind of right. Are both of the installations computer members and in a domain? If the answer to that is yes, then the computer names are different. There is not suppose to be an issue here, but the Domain adds to the SID. I am assuming this is the case. When the domain adds it's portion to the sid, as long as they are both in the same Domain the well known security identifiers are the same, for well known objects. But for that to happen the computer now has its own unique security identifier, which is different for each.

Now with that said, if both of the computers are joined to the same domain and have unique names, then there should not be an issue. If one computer is in a workgroup and one is in a domain, or if one has file and print sharing and one does not then there is an issue. The KB does describe the exact problem, I am just not sure how it pertains to a dual install. Let me do a little more research and I will get back to it on Monday, hopefully you will find the answer! ;)

J

I forgot one thing, Windows 2000 is supported as a dual boot with Win95, Win98, WinME and Windows NT. Windows XP is kind of supported, but you must configure them as above, same domain different names and they must be joined properly so that their SIDS are identical, as oBda suggests, in regards to well known security principals. Windows 2000 and Windows 2000 has never been a supported configuration, and I am not sure why. Maybe we will figure that out.

J

I found one other case in which this issue occurs and it is related to extending dynamic disks. The issue is resolved (or supposed to be) by installing Service Pack 4. What service pack are you running?

J

jdeclue:

It's a very simple pier to pier network with no need to log into a domain.  Service Pack 4 is installed on both partitions.  I looked at dynamic vs basic etc...  Keeping in mind...  Only one OS "Windows 2000 Professional" will be running at a time. The SID's should be unique...  Do to different CD-Keys and OS's, True?  

I am trying to keep this as simple as possible without the need of a third party software like System Commander or some other MultiBoot software.  Based on what I have read, it should work.  

I just joined this service and honestly, there are some pretty knowledgeable individuals that participate within this service, including yourself.  


I will try another HDD with NTFS to rule out any hardware issues and if that fails I'll try FAT32.  Hopefully we can figure this out.  I am sure I'm not the first person trying to do this.

I'll List the Hardware I am using...

Compaq EVO D510 CMT
P4 2.8
1 Gigabyte RAM
Intel Pro 100 VM Embedded NIC
Intel Extreme Video Embedded
Western Digital 40 GIG HDD

Thanks to all for your suggestions and help!

Joe

jdeclue & oBda:

some further developments...  I ran chkdsk and chkntfs and no issues were noted.  I cleaned and purged to event logs and attempted to create the problem.  With great success I was able to reproduce the issue mutiple times however, the "SYSTEM" event log was corrupt so I could not see any notifications.  Additionally, on 2 cases I received an small window indicating an error stating "Unknown Hard Error" with a red "x".  The system was extremely slow, explorer dumped, navigating was next to impossible, then the system eventually rebooted on its own, "This is the first time this happened".  During the reboot the BIOS screen noted there was no HDD installed (the system didn't see the HDD) and requested press f1 to continue or f10 to enter setup.  I powered down the pc, disconnect and reconnected the cables to the hdd, booted the system again then, it recognized the hdd.  I booted back into the OS "Windows 2000 Professional" and launched Event Viewer...  the "System" event log was corrupt and nothing was abnormal in the application event log.

You guys have been great...  I am confused with this issue.    


I am using a western digital 40 GIG with 2 PRIMARY partitions "C" & "D" and the type is basic.  No logical drive or dynamic disks are used in this configuration.  Everything in working properly in the device manager, no unknown hardware or (red "x"'s) indicating the hardware is malfunctioning or needs drivers.

Joe

Are they dynamic disks or basic. You may want to keep them basic. I can't find much regarding this actual problem.

oBda, I made a mistake and assumed the computers were in a domain. My bad. So here is why that makes a difference. Again you are kind of right, but as soon as a computer joins a domain, the well known security principal are given the domain portion of the SID. THis is shown in the article above by the "domain" designator in the SID. At this point the identifier is now different, but the same within a domain. But in order to access shared resources you must have a number of keys related to those sids on your token, while the sid for an account like "administrator" is now the same within a domain, the combination of credentials on your token identify your account and your computer. So, does a well known secerity identifer change .. yes. In addition, the actual SID is not the only piece of the pie, as there are tokens, credentials and methods of authentication that take place which combined, distinguish the user, computer and access to a resource. Services.exe, and other applications which attempt a secured authentication process rely on much more than a SID... and if the stars and moon are not aligned then you will have a problem.


"Unique Computer Name
You can set up a server so that it has multiple installations of Windows 2000 (using any Windows 2000 product) or Windows XP (or any Whistler product) on multiple partitions. However, you must use a different computer name for each installation if the computer participates in a Windows 2000 domain. Because a unique security identifier (SID) is used for each installation of Windows 2000 on a domain, the computer name for each installation must be unique—even for multiple installations on the same computer. " ------MICROSOFT
http://www.microsoft.com/windows2000/techinfo/administration/management/mltiboot.asp


J

If the BIOS doesn't recognize the HD, then it seems like that's indeed hardware related. Is the CDROM connected to the same port as the hard drive? If so, make the HD the master on the primary IDE, the CD master on the secondary.
In W2k Device Manager, check if the CDROM is configured to use DMA; W2k for some reasons usually uses PIO (if you're using the MS IDE drivers, it's under properties of the IDE channel the CD is connected to, otherwise it needs to be configured with the chipset software you installed).
If you have Ghost or something similar, you might try to transfer the contents of the HD to a new one and try if the problems persist.
Either way, if you have important files on that HD, make a backup of them.

To get your system event log working again, you need to delete (or move) the corrupt log file:

Start services.msc, set the start type of the Event Log to "Disabled", reboot your machine.
Move (or delete) the sysevent.evt file in %Systemroot%\system32\config.
Start services.msc, set the start type of the Event Log to "Automatic", reboot your machine.

How to Delete Corrupt Event Viewer Log Files
http://support.microsoft.com/?kbid=172156

Here's a post-SP4 hotfix for that:
Event Logs Are Corrupted
http://support.microsoft.com/?kbid=829246

This is too funny, how did we all get goin at the same time... ok enough of the flaming... this may be getting a lot easier... ;)

J

jdeclue,
as far as the well known SIDs are concerned, it really doesn't matter whether the machine is a member of a domain or not. These SIDs never change. The *local* group Administrators, for example, has the SID S-1-5-32-544, worldwide, on any NT based installation, whether the machine is member of a domain or not (try it for yourself with PsGetSID from http://www.sysinternals.com/ntw2k/freeware/psgetsid.shtml). That is why you can access files on the other (NTFS) partition at all; if the default permissions for the file system were applied to machine specific accounts, you wouldn't have access to files on a partition were another OS resides. You wouldn't even be able to take ownership, you simply wouldn't be able to gain access.
The *global* group domain administrators of course have a domain specific SID, but this group (if the machine is domain member) will only be a member of the local group Administrators, and the Full Access NTFS permissions are still applied to the local Administrators group.
NTFS permissions are not the issue here, completely independent of domain membership or not.
And, no, I'm not flaming. I'm just correcting.

I know you wish to correct, the problem is that I don't disagree with you regarding a local sid, the issue (which no longer has anything to do with jplugins question) is that when a computer joins a domain and uses resources many of the sids are independent... well known sids which contain a domain reference are not universal. These SIDS do get applied in the access control lists of resources, ntfs or otherwise. Join a computer to a domain and put shares and file permissions for domain accounts... then put up a different windows 2000 machine on the computer and start accessing those files, stick the second in a workgroup or different domain. Any process which has to enumerate the aces and match them to tokens will have a serious issue. Many processes use RPC and LPC to travel the stack, in which case they use authentication. The machine expects that the local security is correct. While I agree with you that a SID displayed is an unknown Sid (orphaned), I differ here in that a machine does have an issue with an unkown or corrupt security principles. Foreign security principles are handled on a domain level as a result of trusts, broken trust and removed trusts. But a workstation does not handle foreign security principles like a domain does. Even a domain has an issue if the foreign security principle is introduced without some concept of the original trust. Essentially, by dual booting a windows 2000 worksation, I can make one side see the equivalent of a foreign security principle, which was never introduced through a trust, which to a workstations is a corrupted SID. That needs to be handled very different than an orphaned sid.

I will be honest with you, the only reason I know about this is because I have written security tools which deal with sids and aces. And when developing certain apps, when I incorrectly set local permissions with wrong sids (and the workstation is a member of a domain), it really screws things up.

J

jdeclue & oBda:

Thanks for Helping.  It's resolved.  Western Digital is my Hero.


Joe

Thanks jplugin, I hope the next time you post, I can help a little more ;)

J