• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 288
  • Last Modified:

Is this sysprep really sysprep

I have an associate that does something and I just need to verify it's right regarding Windows Sysprep on Windows 7.

We have a small shop and simply use Ghost to make our images.  Here's what I do: 1. I set up my image like I want it. Then I make a copy, Then when I deploy to a new box I run sysprep first thing after putting the image on the new box. Nothing fancy, just generalize and reboot.

He sypreps his image first. He runs generalize and shutdown and THEN makes his image.
Of course I see advantages and disadvantages each way.  I am aware of these, but the only thing I am wondering about is this: Is his method doing the same thing as far as randomizing the new box as mine does?  The assumption here is that Sysprep does most of the prep and cleaning up BEFORE shutdown and does the randomization needed to make the computer UNIQUE after the reboot. These Windows 7 boxes are going into a  2008R2 AD environment. That is a valid assumption, isn't it?
0
MrSlithy
Asked:
MrSlithy
  • 4
  • 4
  • 2
  • +1
6 Solutions
 
Joshua GrantomSenior EngineerCommented:
His method does generalize the machine just like your method however, Running sysprep after installing the image is not a suggested method.

When you sysprep before making the image it makes it easier to install the image on various hardware with different HALs, hardware, drivers, etc...
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
The PROPER way to do things is sysprep FIRST, then make a copy, then deploy.  I'm 95% certain that what you are doing is leaving the machines in a technically unsupported state while what he is doing is correct.
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Please reference the following link which supports my previous comment:
Unsupported Sysprep scenarios
http://support.microsoft.com/kb/828287
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
footechCommented:
The method your associate uses is the typical route.  I would also add taking an image before running the sysprep to help with avoiding rearm issues.  In the end the method you use will do the same thing as far as the cleanup and randomization, but I can't say I see any advantages to it.  The other method allows the (sysprepped) image to be used with a number of deployment tools (like WDS), where it would be difficult to implement your method.  I think it's also more efficient.
0
 
MrSlithyAuthor Commented:
Lee, I saw the article. its funny though, I just dont see difference:
method1 to make image:
Method A
1.  Clean install, set up apps. make image.
2. Copy image to different box(es) and run sysprep before joining domain and deployment

Method B
1. Clean install, set up apps, run sysprep/shutown. make image
2. Apply this image to new machines.

Thanks

Whats the difference?

Just trying to understand.
0
 
Joshua GrantomSenior EngineerCommented:
Per my post above,

If you do not sysprep the machine before making the image it can cause issues with the

HAL - Hardware Abstraction Layer and driver issues because it can install the wrong drivers and processors. This will cause the machine to have random issues.

http://en.wikipedia.org/wiki/Hardware_abstraction
0
 
MrSlithyAuthor Commented:
footech, now that I understand. We dont use any more advanced deployment methods but I could see how it would HAVE to happen this way in these deployments. And I could also see how Microsoft doesn't seem to support my method in light of these more typical ways and the problems my method could cause because the complete automation of deployment is broken by someone needing to "sun sysprep" which cancels out the ability to automate.
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
When you sysprep and generalize, it helps clean up the hardware database so when it starts next, it's kind of starting from scratch - the way you're doing it, it's like slamming an existing system into different hardware then removing parts of it... it's messy and with something so complicated could cause problems that might not surface except under very specific circumstances and in such a way that you'd never connect the problems together - unless you were open minded and willing to make the link between your deployment methods and the problems.  Even then, it would be a guess until you spent hours trying to troubleshoot.
0
 
MrSlithyAuthor Commented:
Lee,

So we are making an assumption that, putting it into the same model computer means the same everything. But who knows what speck may have changed under the hood?  Now THAT I understand.  IT might be OK if I KNEW there was absolutely no difference in the computers between the one on which the image was made and the one I am placing the image on next, but that is not a good assumption to make.  I guess I can argue it doesn't make a difference ASSUMING this that and the other thing, but better to Sysprep/shutdown/make image to be sure - - -especially if that's what MS wants.

Thanks
0
 
Lee W, MVPTechnology and Business Process AdvisorCommented:
Keep in mind, certain things like MAC addresses change as do other components on the motherboard.  Ever notice that when you boot up a "transplanted" motherboard/hard drive Windows is installing devices - even if the hardware is consecutive serial numbers?  Ever notice Windows often reinstalls your mouse or USB flash drive if you switch USB ports?
0
 
MrSlithyAuthor Commented:
Yeah, I see it now. MAC address reference was a great way to get it into my head.  

OK. I have a confession to make.  I haven't deployed any the way I describe. But the subject came up and no one could really define the differences too well - - -at first.


Thanks
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 4
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now