Radified Community Forums
http://radified.com/cgi-bin/yabb2/YaBB.pl
Rad Community Technical Discussion Boards (Computer Hardware + PC Software) >> PC Hardware + Software (except Cloning programs) >> Sysprep v1.1
http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1036397317

Message started by Citizen_Kang on Nov 4th, 2002 at 3:08am

Title: Sysprep v1.1
Post by Citizen_Kang on Nov 4th, 2002 at 3:08am
Hey Rad how's it going,

Have you ever looked-into\researched this MS utility? - I did a search on your BB and at least one user has mentioned it before.   This tiny app (63 KB) appears to be immensely (super) powerful, especially if used for its implicit purpose: allowing a network admin to do a base install of W2K or XP onto a  workstation and then deploy an image of that setup, via a 3rd party app like Ghost (or I suppose MS's own Intellimage), to a host of non-homogeneous client machines!!! ...simply amazing by the looks of the documentation.  (Obviously there are some caveats, but it appears that once you configure Sysprep for your installation environment and needs, your rocking)....If you thought Ghost packed a lot of punch for its size, I get the feeling you would consider Sysprep to be very De la Hoya-esque.  

[ Side Note: isn't it incredibly funny how some of the truly great apps that allow you to push the envelope of your computing activities, with the most ease and flexibility, and with the least overhead, and which result in making your computing  experiences\adventures more enjoyable and productive (which collectively, I suppose, could be summarized as, equivalently, the digital pursuit of happiness)  are so small in size!]    

Anyways, I find myself needing to utilize Sysprep now for a  much much less complicated (Ghost) imaging need.  I came across it on Symantec's support site, as they reference how to use it as a solution to a particular problem that I have run into with Ghost.

Cheers, CK
 


Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 4th, 2002 at 3:16am
Note: Sysprep v1.1 is the latest version for W2K.  XP comes with its own version that is packaged on the installation disk.  The W2K installation disk also comes with Sysprep, but it was an earlier version that only supports deploying an image to clients that are homogenous to the parent machine.  This eariler version still has some neat functionality - setting up SIDs etc. - but its definitely not as cool as the latest version and all the tricks it can do!

cheers, CK

Title: Re: Sysprep v1.1
Post by Radministrator on Nov 4th, 2002 at 3:32am
Hey Kang.

No, I have no experience with sysprep, but I did a search a read up on it a little. It's a M$ product:

http://www.microsoft.com/windows2000/downloads/tools/sysprep/default.asp

Yes, it is funny how some of the most powerful utilities are so small.

Gonna read a little more.

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 4th, 2002 at 12:14pm
Go back one page from that MS link you posted to this one, and on the right hand side there is a "Read document" that you can download.  Also see the documentation that is contained in the actual Sysprep download.

You can also read this Symantec discussion group article and go to the link that Symantec provides the user for their problem i.e. this page

It is the virtual mem problem outlined in the first Symantec link that I am trying to circumvent, and it looks like Sysprep is the answer....don't know yet, got some reading to do myself...and then the fun shall begin.  Will let you know how things turn out.  

Cheers, CK

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 4th, 2002 at 7:45pm
Doh!

Although I became aware of Sysprep by way of mishap, I am very happy to have discovered it because it may prove quite useful in the future.  However, it is not the solution to my current problem....although I'm sure it would work, but I don't particularly need or want to rebuild the PnP driver database on the restored image.

Got some investigating to do (Ghost Walker might help but don't know yet).  Anyways, here's what I'm simply trying to do:

Ghost 2K3, W2K, NTFS only, 2 drives.

Drive number 1 has 5 partitions.  Drive 2 has 2 partitions

Using Ghost nomenclature of Disk : Partition,  1:1 is from where I boot. Using Ghost, I successfully create a valid image of 1:1 on 2:1.  I then boot back into W2K and move that image from 2:1 to 1:4.  Using Ghost, I then successfully restore the image now contained on 1:4 to 2:1.  Power down and remove Disk 1 from the system.  Boot back up with only Disk 2 in the system.  Everything looks good and then just before you get to the desktop screen, a Virtual Mem error comes up and you can do NOTHING.

This and this both mention a -FDSP switch as a possibile pervention (I think this may have come up in one of the other threads here on the Radified forum too...will have to check)

And in this thread here a couple of references about GUID might be on target.

Anyways, I goto go walk the dog...it will give me some time to think this through a bit....(maybe)

Cheers, CK



Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 4th, 2002 at 11:11pm
Hey Rad,

Problem solved...with only disk 2 in the system, I booted into DOS and then used Fdisk to set 2:1 as the active patition.  Rebooted into W2K no problem.  It then proceeded to set up the "new" hardware configuration and after a requ'd reboot, presto, all is well.  Its always the little things I tell ya..(the devil in the  details, so to speak).  

Well now that I have brought my brief ordeal to a close, I have reminded myself how important it is sometimes to take a step back away from a problem, give it some rest and then maybe come back to it from a slightly different angle.

And, as I somewhat alluded to in my earlier post, having been made aware of Sysprep, I am now that much more the richer from the whole experience.

Cheers, CK
 
....scurries off to live another day....
   

Title: Re: Sysprep v1.1
Post by Radministrator on Nov 5th, 2002 at 12:25pm
Congrats.

What gave you the idea to set 2:1 as active partition?

I would've thot that, once you remove disk 1, partition 1 of disk 2 would automatically be assigned as active partition (it will become disk 1 soon as you remove the other disk).

squeeky had a thread mentioning the -fdsp swithch here:

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1035845774

i like the ghost disk:partition nomenclature. It's easy to understand.

Title: Re: Sysprep v1.1
Post by Radministrator on Nov 5th, 2002 at 2:21pm
Ran across this:

http://www.anandtech.com/guides/viewfaq.html?i=115

Not sure if it helps.

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 5th, 2002 at 6:02pm
Hey Rad,

Hmmm...where to start... maybe with addressing your posts first:


Quote:
What gave you the idea to set 2:1 as active partition?


One of the threads I read...which one and where, I can't remember.....too many hours of reading ghost, syspret and other mumbo jumbo fried my short term memory...which will lead to other problems/considerations as you will soon read below.


Quote:
I would've thot that, once you remove disk 1, partition 1 of disk 2 would automatically be assigned as active partition (it will become disk 1 soon as you remove the other disk).

Yes, thats what I would imagine too, which got me thinking today...

And yes Squeaky's thread was the one I had in mind.  Will have a deeper look at the Anand article later (right now Sysprep has no bearing on my well being....but as I stated earilier, may very well come in handy someday down the road).



Okay, here's what's going on now:

I was happy to get things functioning with my lillte project last night, however today I started to think about what I had done to resolve the problem and too many things didn't add up right.  So, wanting to be able to reproduce my success (and also being someone who is a real sucker for punishment - a.k.a someone who doesn't subscribe to the "if it ain't broke don't fix it" school of thought), I proceeded to replicate my imaging activity.

To recap those steps:
- in DOS, imaged 1:1 to 2:1
- boot back into Win, copied image on 2:1 over to 1:4
- boot in DOS, restored image on 1:4 to 2:1
- shutdown, removed disk 1 from system,
- with only disk 2 in system, boot normally

- from here windows starts to load up, it gets to the preparing networks part and then you get the Low Virtual mem message.  You can click ok, but windows drops to a snail's pace and then another Virtual mem message comes up...and if you click okay, the message just comes back after about a quarter of a second...that's it, no further you may go, endless loop

So, thinking I had figured this one out last night, I proceed to boot into DOS and use Fdisk to reset the active partition.......Result: no luck, same endless loop described above.  I then proceeded to go back into DOS and try all kinds of Fdisk mumbo jumbo, all to no avail.

Frustration sank in....too many lost hours, and so many reboots later, I was back at square one.

So I says to myself, "self, what the hell did you do yesterday that got things working?".   Sad fact was, I had tried many things yesterday, in various order, and documented none of my steps.......simply put, I introduced so many variables to be sure what the winning combination ended up being.

So, I stepped back.  Thought I'd try this from the start.  Reformated 2:1 with the W2K installation CD.  Hooked disk 1 back up and restored the image from 1:4 to 2:1.  Unhooked disk 1 and fired back up normally...no luck...tried playing around with the active partitions some more....no luck, getting no where...

Then I remembered that at some point I had tried using the /MBR switch on Fdisk yesterday (which is supposed to rewrite the master boot record on the system disk)...at the time it didn't appear to do anything except access the floppy (actually I thought I had hosed my WinME boot disk at first).....well, I decided to try again and to be a little observant this time round....yep, sure enough, there was some activitiy on the hard disk.  So I gives firing into Win a whirl again...and...and....bango! Windows fires up, reconfigures the setup, reboots and comes back perfectly.

So, thats where I stand now.  Not 100% sure if the /MBR switch was the only thing that solved the problem...once again, I've introduced too many variables.  But I know this much, without it, I was getting no where.

I Can't even remember where I found out about the/MBR swtich from (most likely from this thread or one of the links provided in it.  BTW, you can read up on this switch in this MS Fdisk article.

Later tonight I going to repeat the above image activity and then just try Fdisk /MBR to see if it alone solves the problem.  Won't be happy until I can get a reproducible fail safe solution...which I think I'm pretty close to, but right now I've got some other stuff that needs to get done....

will let you know later how things turn out

CK

Title: Re: Sysprep v1.1
Post by Radministrator on Nov 5th, 2002 at 6:36pm
fdisk /mbr would make sense.

I've resorted to it more than once, usually following fubar linux installs, when nothing else will work.

fdisk /mbr can work magic when nothing else will.

was reading your ms linky.

they claim the mbr is also called 'partition table'  I thot these were two separate things.

Lots of great arcane info there.

I know that feeling of screwing with something to figure out wtf is going on. I have been up until the sun comes up sometimes, cuz i refuse to quit on a problem.

Sometimes it's best to let sleeping dogs lie.  :)

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 5th, 2002 at 11:36pm
Hey Rad

I can now say,  100% proof positively, that it was /MBR, and nothing else, that brought the restored image back to life.

Unfortunately, in the process of taking the ide ribbon out of disk 1, I snapped one of the plastic tabs on the side of the ribbon interface.  The good news is that this one is probably repairable with a little epoxy ... which is in stark contrast to others that I've been not so gentle with and fubar-ed (oh like the last one about a year ago).  The bad thing is that I only have one ribbon right now (see previous sentence for details), and now its down to the one connector for the time being .... Maybe needless to say, but when I broke the last cable a year ago I swore that I'd never buy another one, that I would become a holdout until SATA finally arrived.  My anticipation  has now only been heightened...just think, no more stupid ribbons, flimsy interface connectors or jumpers!

So, minor set back with the ribbon aside, where am I left now?  Wondering....wondering why or how all this Virtual mem errors occur in the first place.  Oh sure its great that using /MBR will resolve the problem, but it would be nice if it wasn't there to begin with.

This leads me to my next consideration, perhaps all it may have taken was removing the second drive from the system just before imaging....kind of just like how you would run sysprep and then image right after.   Now, if that stupid little tab had not snapped I would be well on my way to finding out right now.  When I get it fixed (tommorow) I'll try it out:  

- start in windows with both Disk 1 and 2 in system
- device mangler -> remove disk 2, will require reboot
Now here's the fork in the road:
- should I shut down and physically detach disk 2 and boot back into W2K (letting W2K completely flush and reconfig), and then shutdown, re-attach disk 2, boot into DOS and then do the imaging
or
- restart into DOS and do the imaging right away

I kind of think that the former would be the better opinion, as it gives Windows the opportunity to completely flush the disk 2 from the system....don't need or particularly want disk 2 remnants in the image file.

I also have my suspicions that neither case would resolve the Virtual Mem error.... I'm guessing that an logical error related to the MBR would still cause trouble.


Dispite all the hassle this may seem, I'm really glad its happening now.   This is my first attempt with Ghost 2003 and working exclusively in the realm of NTFS....I want to make sure things will work later on down the road, especially at those inconvinent times when that all so annoying guy Murphy decides that you need them to work.   Second, I normally wouldn't image and restore the way I have been....I just want to try out some software (beta testing) and don't want to f*ck with my good drive.  Hence the reason for copying the image back to 1 and then restoring to 2.  

I have to say, this experience has raised further concerns for me about 2K3, such as:

What if I imaged normally i.e 1:1 to 2:1 and then had to (under non ideal circumstances) restore the image back to 1:1?  Is it going to work without hassle?

Or how about if disk 1 dropped dead and I was forced to get a replacement.  Say, then, I decide I no longer want a 5 partition configuration on my new disk 1 and set it up with fewer (or even 1 for that matter).  Is restoring the image to the new disk 1 going to cause windows to kick and scream when it boots up?

These are a couple of important questions that I want to iron out completely before I have entire faith in a pure NTFS realm.  My bets are on Ghost working fine, but I', still gonna have to prove it to myself first.

Cheers, CK

Title: Re: Sysprep v1.1
Post by Radministrator on Nov 6th, 2002 at 12:59pm
All valid questions.

I like that you are testing things before you actually need them.

Whenever friends/family pump me for guidance, I always fall back on what I know works for sure .. things I've actually done. Even in the guides, I try to note when I haven't actually done something.

Friends will say shit klike, "Well, I could do it this way, It *should* work."

I say, "Yeah, should. But things don't always work the way they should." If they go their own way, they're on their own.

A nomal image restore restore back to 1:1 should work. This I've done.

If disk 1 dies, and you replace it with a different partitioning scheme, I dunno, cuz I've always used identical partitioning schemes with the new drive. This has always worked for me .. about 3 or 4 times now.

Then again, you are working solely with Ghost 2k3 and NTFS drives .. something I've never done. It wouldn't surprise me if you stumbled upon a wierd configuration glitch.

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 7th, 2002 at 11:19pm
Follow up:

Yesterday I did some testing of some various software.  One of the things I tried out was a driver update for my NIC.  It didn't go so good and excising it from the system was not working.  Rather then wasting time combing through  the bowels of windows' resistry and inf files, and  eager to restore my internet connection, I, again, just restored the image I have on 1:4 to 2:1 .... Because my one 80pin IDE ribbon is down to just the one (end) connector (see one of my above posts, and oh, BTW, I ended up destroying the middle connector instead of fixing it - DOH!), I  connected Disk 2 on its own channel with the 40 pin ribbon used for my CD/DVD Roms....surprise, no Fdisk /MBR required this time!

I'm not sure about what to make of this change in events.  Perhaps it was because I had already "corrected" Disk 2's MBR the last time I restored it and that I never entered into W2K with the two disks connected this time (would have been catastrophic to 1:1 if I had without without formating 2:1 first...plus I had no reason too, seeing that, this time around, the image file was already happily residing on 1:4)?  Perhaps, although unlikely, it was strictly because I used two seperate channels this time?

My money is on W2K rewriting the MBR of all disks it sees....Testing this thouroughly would require running through a couple of imaging configurations/steps:

1) Using the 2 unique channel setup:
a)  I would reformat 2:1 and then restore the image to it without ever going back into W2K when Disk 1 is reattached to the system
b)  reformat 2:1, but this time go back into W2K with the two disks attached (i.e. booting off 1:1).  Then go back into DOS and proceed with the image restore  

2) Run things off a single channel configuration:
Reformat 2:1 and then restore the image to it without ever going back into W2K when Disk 1 is reattached to the system.

The outcomes of those tests would most likely shed some pretty good light on what's going on....really, the only major time consumer would be the formating 2:1 step from the installation CD, everything else is minimal down time....so maybe on Saturday when I can run all this while doing something like sorting and folding laundry .... we'll see.

On another note:  I happened to discover by chance a little software glitch between Winamp 3 and the Age of Mythology trial.  If you just leave Winamp open (not playing anything) and have it set to "always on top" and then launch AOM, then after the opening (and very cool I might add) trailers to the game, at the game loading/options screen, the sound starts crapping out as Winamp tries to come back on top....at least, this happens for me...your milage may vary...

Hmmm...this sysprep thread has fully transformed itself into an investigation of some ghost2k3 perculiarities....perhaps you or I should edit this (rename or remove portions to another thread) to properly reflect the subject matter...just a thought.

Cheers, CK





Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 8th, 2002 at 10:59pm
Hey Rad

Well I did some more testing (1a and 1b from above post).  The two channel long shot can definitely be tossed out the window as, although 1a passed without a need for fdisk /MBR, the 1b test required a dose of /MBR.

I interpret this as a clear indication that W2K does indeed configure the MBR of every disk it sees.   But does this include the installation CD too?  I don't know, it would require refining my test a little more.  

This much I know: at what point, and how you remove or introduce a disk to your system may well end up affecting the imaging/restore process.

I'm not certain if your interested in these finer details or not..or if what I have been writing is clear enough to follow....if it is and if you are interested, I can continue describing my steps to get to the source explanation.

Cheers, CK




 

Title: Re: Sysprep v1.1
Post by Radministrator on Nov 9th, 2002 at 1:40am
It's clear.

I always configure new disks exactly as the ones they replace.

Haven't had a problem with that yet.

Everytime I install a new disk, I see W2K says, "Installing your new hardware", so I know it knows the difference between new & old disks, even tho the new one may be the exact same make & model & partitioning the same as the old one. Then it requires a reboot.

When it sees it, maybe it rewrites its MBR?

Sounds like your getting lots of experience restoring images.  :)

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 12th, 2002 at 11:52pm
Hey Rad,

Well it looks like even the installation CD will write to the MBR.  Proof:

1) Start with only disk 2 is in the system and boot from a fully functional W2K on 2:1.
2) Restart and boot from the installation CD.  Reformat 2:1.  Shutdown.
3) Attach disk 1 which has fully functional W2K on 1:1.  Boot up off 1:1 with the two disks attached.  
4) Restart system and boot into DOS.  Start Ghost and then restore the image held on 1:4 to 2:1.
5) Exit Ghost.  Shutdown system.  Unattach disk 1.
6) Restart system normally.
(Note: Steps 1-6 are exactly test 1b from about post, just formally written out)

The result, which is now predictable and reproducable -> a virtual memory error which does not allow 2:1 to fully boot.
Now instead of remedying the problem with Fdisk /MBR:

7) Restart system and boot from installation CD.  Reformat 2:1
8 ) Exit and turn off system.  Reattach disk 1.  
9) Boot up into DOS.  Start Ghost.  Restore image from 1:4 to 2:1.  Exit Ghost.  Turn system off.
10) Unattach disk 1.
11) Reboot normally

The result -> W2K boots up fine off of 2:1.

Interpretation:
@ step 1 -> disk 2, obviously, has a correct MBR.
@ step 3 -> W2K on 1:1 writes to and changes disk 2's MBR
@ step 6 -> disk 2's MBR is incorrect = no boot
@ step 7 -> W2K on installation CD writes to and changes disk 2's MBR
@ step 11 -> disk 2's MBR is correct = boot

Summary Pts:
- The way you introduce a disk to a system may indeed affect your ghosting operations
- Notably, W2K (and I presume XP) will configure a disks MBR.  The way that the disk's MBR is configured is dependent upon wheither W2K "sees" other disks in the system
- Fdisk /MBR is the quick and easy remedy to these MBR related virtual memory problems.

Lastly, I would like to draw attention to what one poster in this thread said on 06/24/02:

"I may have got a bit adventurous about the order in which I deleted/created partitions, copying from secondary to priamry etc - whatever Partionmagic was happy to let me do :). The trouble is, what PM allows you  to do is not always what w2k/XP would be happy with. There are no warnings about the consequences of your quite seemingly sound operations.  In future I would endeavour to perform operations in the order w2k expects, not what PM allows me."

Obviously, that individual was dealing with a slightly different set of circumstances.  However, the context of their message is bang on, and it can easily be extended to include Ghost within its scope.

------------------------------
Well, that concludes my experimentations with this problem.  I'm happy enough with my findings, and don't really care to delve any further.  As it stands, I'm perfectly happy with Ghost2K3 and I am confident that it will work the way I want it too when I need it too the most.

If anyone else is reading this thread besides you Rad, the least they should glean from it is the simple fact that Ghost is, indeed, an industrial strength back up and recovery program.  How many times have I restored an image over the past week?  I honestly don't remember....probably upwards of 15-20.  How many times did I completely hose my system over the weekend trying out different drivers and some other software?...4 times.   How many minutes did it take to restore an image and get me back up and running?.....probably about 10 minutes total for those 4 times (most of which is spent reattaching my disk 1 and rebooting into DOS!).    I even tried creating an image in a one disk configuration...took a whopping 3.5 minutes as opposed to the usual 50 seconds in a two disk configuration....forgot to try restoring in the one disk configuration, but I'm sure it would take only ~five minutes or so.

Talk soon, CK




Title: Re: Sysprep v1.1
Post by Radministrator on Nov 13th, 2002 at 3:00am
Excellent post. I read it 3 times.

Any speculation on WHY W2K rewrites disk #2's MBR in step 3.

I could see it doing this during an install, but had no idea it would do this during a normal boot.

Do you thinks it's cuz you just reformatted the disk and the O/S wants to 'own' the new/blank disk?

Does reformatting wipe the MBR?

Title: Sysprep v1.1
Post by Citizen_Kang on Nov 13th, 2002 at 9:10pm
Damn you Rad, you got me thinking again....

I wrote up a lengthy reply and realized that it was contradicting my conclusions and that I didn't completely understand what is occuring...then a plausible theory started presenting itself to me...going to write it up and perhaps do a little research for some support....but it will have to wait till later on tonight.....the dog is driving me crazy right now and so I better go take him for a walk.

CK

Title: Re: Sysprep v1.1
Post by Radministrator on Nov 14th, 2002 at 12:59am
:D

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 14th, 2002 at 2:25am
What did I say, about ten posts ago, about taking a step back from everything to work things out?  I really should stop dispensing advice if I can't follow it myself.

1. First off, I recently said
Quote:
Well it looks like even the installation CD will write to the MBR.

Dumb bastard..Is it too late to recant? Because:

2. You stated
Quote:
Does reformatting wipe the MBR?

I believe your right. My testing would seem to indicate that it does, and I have refined my conclusions based upon this fact.  In fact, this is the key point, and I can't believe I overlooked this.   I was just too caught up in the W2K changing disk MBRs on the fly theory.....which, however is still partially correct....I just haven't figured out how an instance of W2K running from the installation CD behaves yet.

(Note: I quickly re-read the entire thread, and in early posts on the first page I mention reformating but having no luck...but if I recall, I was still hooking the two disks back up and booting into Windows from 1:1 just to copy the image back to 1:4 from 2:1....unfortunately, I did not detail all the steps I was taking)

3.
Quote:
Any speculation on WHY W2K rewrites disk #2's MBR in step 3.
 As outlined in the above point, I now believe it is because the reformating performed in step 2 of the test wipes disk 2's MBR clean as a whislte [grumble]whatever that's supposed to mean[/grumble].  When W2K starts off of 1:1, it probably looks for a "logical signature" (more on this in a minute) in disk 2's MBR, but finds none and so writes a new one.

4.  
Quote:
Do you thinks it's cuz you just reformatted the disk and the O/S wants to 'own' the new/blank disk?

Reformat wipes MBR, but "OS ownership" I don't think so.  I just believe W2K likes its universe to be really logically organised ... will try to explain in a moment.

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 14th, 2002 at 2:28am
I just got a message is too long error so I'm splitting this up....didn't realize there was a limit placed on the amount I'm allowed to spew  ;)

5.
Quote:
I could see it doing this during an install, but had no idea it would do this during a normal boot.

I speculate that W2K checks MBRs each and every time its starts up and will write to a disk's MBR if no "signature"  is found. (At least, I think I have proven that this is the case when W2K is run off a disk partition....but, as I mention in a above point, I'm still not sure about what an instance of W2K running from the installation CD does).

6.
Quote:
Everytime I install a new disk, I see W2K says, "Installing your new hardware", so I know it knows the difference between new & old disks, even tho the new one may be the exact same make & model & partitioning the same as the old one. Then it requires a reboot.  When it sees it, maybe it rewrites its MBR?

According to the revised "KangRadian" theory, W2K should write to the disk's MBR because, being a new disk, there is no signature in the MBR.

7.  Plausable explanation for what occurs in step 3 of the test:
- W2K begins to load and performs a check: "am I booting up from the correct disk?"
- looks at disk 1's MBR signature -> disk 1's MBR signature indicates that it is the boot disk
- W2K continues boot from the disk 1 (loading files and initializing system resources)...
- gets to disk 2 -> looks for MBR signature, but doesn't find one
- W2K writes to disk 2's MBR, giving it a non boot disk signature (and this step will require a reboot to properly configure the disk --- just like what you have to do after changing anything with Fdisk!)

Plausable explanation for what occurs in step 6 of the test:
- W2K begins to load and performs a check: "am I booting up from the correct disk?"
- looks at disk 2's MBR signature -> disk 2's MBR signature indicates that it is a non boot disk
- W2K thinks that crucial files (like the page file) are not on disk (the only one in the system)
- loading of necessary files and initializing system resources is halted

Sketchy explanation for what occurs in step 11 of the test:
- (Recall, the Step 7 reformat wipes disk 2's MBR clean)
- W2K begins to load and performs a check: "am I booting up from the correct disk?"
- looks at disk 2's MBR signature -> disk 2's MBR has no signature

Stop.  Now this is where the conjecture gets a little fuzzy, but it still flows from a logical perspective and I will do my best to convey this...just keep in mind the "I think, therefore I am" idea...

Perhaps no MBR signature is good enough for W2K.  Obviously, if there is a "boot disk signature" W2K proceeds, and I believe I have illustrated that if the disk gives a "non disk signature" things will come to a halt (at least in a case, where there is only the single disk in the system).  But in a case where W2K gets nothin' back from the disk, its got to be saying to itself, "well I started from somewhere, and that somewhere is got to be here!", and so proceeds to look for the necessary files from its source.....Thus, what I am proposing is that W2K will respond accordingly to three possible disk MBR variables: [boot disk, non boot disk, no signature]=[boot from source, look elsewhere, boot from source default].   In this light, I see W2K as being a blindly obedient but philosophical OS.    

Anways, I would hazzard a guess that disk 2 gets its MBR written too dynamically by W2K on the fly.  Are you buying into it?  Logically, I think it makes sense.  

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 14th, 2002 at 2:29am
Chessey Analogy:

In football you have a certain number of players (disks) on your team.  You can choose anyone of your players for a certain position, but hopefully you will select them based upon their natural suitability for such roles as a wide reciever, lineman...(boot disk, storage disk...).  However, the rules of the game also stipulate that certain functions such as pass recieving (booting) are only allowed to be performed by an eligilbe player.  A player's eligibility for a certain positiion/function is signified by their jersey number assignment (MBR)...

Continuing this analogy with my little proof from the above post:

In step 3, disk 1 has already been assigned as a wide reciever (boot disk) and its eligibility for this role has been denoted by writting 81 on its jersey (MBR = boot disk).  Disk 2 then enters the game and is assigned as a lineman, and its jersey is given an appropriate jersey No.56 (MBR = non boot disk).  So then, after step 6, the play starts up but the OS referee sees that you just threw the ball to your lineman...."Wow wow wow", cries the OS as it throws its flag onto the field.  The outcome of its proceeding call is obvious, "Ineligible reciever on the play...", the play is called back and you don't get to boot.  And you can try this play as many times as you like, but the OS will catch you for the infraction everytime.  Simply, you won't be able to use this lineman as a reciever until you make him eligible by changing his jersey number (MBR)....it doesn't even matter that your usual reciever has been sitting out on the sidelines during the play (disk 1 is unattached)...its all about the number (MBR) assignment that the players were given when they entered the play.

Okay, its not the most perfect analogy because W2K acts as the coach, rules of the game, and the referee enforcing the rules....judge, jury, and arbitrator I suppose.  Also the football analogy could be refined a bit, but I'm sure you get the picture.

I (purely) speculate that W2K likes to operate/play within a clearly defined environment and set of rules, and so assigns each disk a specific role at the time it is entered into the system...that assignment comes in form of a MBR signature.

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 14th, 2002 at 12:20pm
So I've started looking around for some support to the modified KangRad theory.  Just doing a google search on the MBR right now.  From this, check out this highlight from what this guy discovered:

"* Although I'd still like to know exactly how these mystery bytes are used by the Windows OS, their meaning is no longer a mystery to me. Rather than looking for answers on the Net, I simply started doing some tests on my own hard drives. In a short time, I came up with all the data I needed to remove the mystery. Most people think the same six bytes are always written to everyone's hard disks at these locations. NOT true! I purposely used a string of ZERO-bytes in the diagram above, because that's how they're hard coded in all the FDISK.EXE utilities for Win 95B, 98, 98SE and ME. As a matter of FACT, if you use FDISK from one of these OSs with the /MBR switch on any drive, all of its original "mystery bytes" will be overwritten with zeros! The FDISK program never writes anything but zeros to these locations. So, what does change these bytes? The Windows OS itself (most likely some little routine burried deep inside a .DLL file) changes the last four of these six bytes!

After discovering this, my first guess was that these bytes might be used during the initial OS setup to let Windows know if it has ever been booted for the first time. But it seems really odd that it keeps looking at these bytes in the MBRs every single boot-up! At some point during the booting of the Windows GUI system, it looks at these six bytes on each drive, and if they are all zeros, it changes the last four bytes to reflect the MBR's drive number and the current time when these bytes are written:"


That, my friend, is what I call pay dirt.  Obviously this little phenomenon is not limited to the NT OS's but is a Windows trademark characteristic.

Cheers, CK

Title: Re: Sysprep v1.1
Post by Citizen_Kang on Nov 14th, 2002 at 12:47pm
The modified KangRad gets modified:


Quote:
Does reformatting wipe the MBR?

Not exactly.  I believe just the 6 byte "signature" in the MBR that the OS reads from (and writes to when needed) gets written over with zeroes during the format process.  

CK

PS. This should be obvious to even the most dimwitted individual
who holds an advanced degree in hyperbolic topology
 ;)

Title: Re: Sysprep v1.1
Post by ketamine on Nov 28th, 2002 at 7:15am
Talk about being at the right place at the wrong time... actually im just a few hours late from visiting here coz I think if got to know about Sysprep v1.1,  it might've saved me the trouble of reinstalling the OS on drive C: coz CleanSweep has this thing of unistalling everything in the program files directory when u uninstall an app THAT u installed while running several windows(or tasks) at the same time.  I finished the OS install just a couple of hours ago.

If only i got here sooner...  :(  

Radified Community Forums » Powered by YaBB 2.4!
YaBB © 2000-2009. All Rights Reserved.