WIM Images
-
Monday, December 03, 2012 11:22 AM
Hi there.
Can sonmeone please clear something up for me? I'm still learning so this maybe a little 'rookie' for some.
I have read somewhere that when you capture a WIM image, the HAL is disconnected, so effectively you could put any WIM image on any hardware. Is this true? If so are there any limitations?
I help run a business which looks after schools, we have around 36 on our books. In each school we map out just two images. A curriculum image, for pupils and teachers, and an admin image (which doesnt contain the curriculum sofware) for the admin/clerical staff. Up until now I have always built an image on each hardware type, then uploaded an image to the server. This new information tells me that i'm doing it wrong and I should just build two images for each site, then continually inject drivers to the WIM image as I come accross new hardware.
So lets say I have a curriculum image, with all the school software on. I then capture this up to the server using MDT2012. Later, the school buy a new laptop for a new teacher and it is a completely different model to the rest in school. If I deploy down my curriculum image and there are 3 or 4 drivers missing, I can simply mount the WIM using ImageX and inject the missing drivers, then from that point on I can image the same model laptop with having to chase drivers.
Have I understood this correct?
Regards JH
All Replies
-
Monday, December 03, 2012 1:05 PM
If you are going to deploy Vista or newer you don't need to consider about HAL.
If you are using MDT you will create a image that is hardware independent.
You will instead import the different drivers and by "mdt rules" the right drivers will apply. There many diffrent approaches when it comes to handle drives in MDT.
Here is some good exemples: http://www.deployvista.com/Default.aspx?tabid=78&EntryID=132
-
Monday, December 03, 2012 3:19 PM
I concur with Henrik's answers. One thing to note though is that adding drivers to the image is counter-productive as it bloats the image and is not generally recommended. That's the point of Henrik saying the image should be hardware independent.
MDT is more than a simple imaging system like Ghost -- it's a deployment system. Thus, although the image is a part of the process, it in not the whole process. For drivers and other hardware specific software, MDT easily injects these into the process after the image has been deployed to the system. There are different ways of getting this done depending upon your environment, but it's all part of MDT. This goes for applications also. With MDT, you no longer have to think in terms of a monolithic, end-all, be-all image. MDT brings flexibility to the table and allows you to dynamically deploy things based upon the run-time conditions of the system including hardware, role, and location.
Jason | http://blog.configmgrftw.com
-
Monday, December 03, 2012 5:53 PM
Drop me an e-mail and I will send you a short guide on driver manamgent with screen shots.
firstlast AT hotmail dot com
- Edited by Amnon Feiner Monday, December 03, 2012 5:55 PM
-
Thursday, December 06, 2012 6:30 PM
Email sent, thanks Amnon.
In each school there are, lets say a maximum of ten different machines, having deployed windows by disk to each machine over time (the hard way) I've yet to see any device that needs more that 5 drivers after a standard deployment.
So lets say there is a maximum of 50 drivers needed for each school in addition to what comes on the windows disk. WOuld that really 'bloat' the images that much? I think it'd be fine so if I can get them in, instead of having an image for each device. I would like to have just four for each site.
X86 - CURRICULUM IMAGE (with Drivers)
X64 - CURRICULUM IMAGE (with Drivers)
X86 - ADMIN IMAGE (with Drivers)
X64 - ADMIN IMAGE (with Drivers)This is my aim. What would you suggest is the best method to achieve this goal?
Regards JH
-
Thursday, December 06, 2012 6:45 PMNo one recommends or advocates having an image for each device. Please re-read my answer. MDT will dynamically "inject" or add things to the system after the base (vanilla) image is deployed. This includes drivers, software, updates, etc. As mentioned, MDT is a complete process, not a simple imaging solution. Thus, the realistic goal as far as the image goes is having a single, vanilla image that you apply to all devices as *part* of the entire automated deployment process.
Jason | http://blog.configmgrftw.com
-
Thursday, December 06, 2012 11:03 PM
No one recommends or advocates having an image for each device.
Some people still swear by it, even in 2012 which is just incredible.
In regards to the original question - I'd also suggest opening up the MDT help file and following it though. MDT is extremely well documented and most people assume the help file won't be helpful so they don't bother looking, thankfully this just isnt the case and it will be able to explain both the theory and the practicalities of making images + drivers.
-
Friday, December 07, 2012 1:04 AM
"Some people still swear by it, even in 2012 which is just incredible."
Those folks are why IT gets a bad name and why I'll always have a job :-)
Jason | http://blog.configmgrftw.com
-
Friday, December 07, 2012 9:33 AM
"Some people still swear by it, even in 2012 which is just incredible."
Those folks are why IT gets a bad name and why I'll always have a job :-)
Well, I'm glad I'm headed in the right direction then. After what I read I knew I was doing it wrong. I simply dont have the time to spend on this that I would like to. I can squeeze in some time here and there in the 'real world' aside of meetings and I'm enjoying getting to grips with MDT. I started with MDT2010 but have never really delved deep enough into it to take advantage of its full features. I'm only applying its uses on a small scale in small environments so I probably wont need to use every feature. However I do I have a 3 server and 4 client test rig at home (vms) which I use to practice on. I have been pointed in the right direction so yes, I have some reading ahead of me.
Working in small schools with low budgets, a lot of the software isnt deployable. There are no silent install commands and some of the software doesnt have MSIs. Some we even have to hack the code to get it to work.
You say ideally you would have one vanilla image that would go to all equipment. Suppose you had quite old legacy equipment that couldnt take 64 bit. Is it possible have one task sequence that would 'automatically' select x64 or x86? That would be handy.
Regards JH
- Edited by _Jonnie Friday, December 07, 2012 11:46 AM
-
Friday, December 07, 2012 9:41 AM
"Some people still swear by it, even in 2012 which is just incredible."
Those folks are why IT gets a bad name and why I'll always have a job :-)
Well, I'm glad I'm headed in the right direction then. After what I read I knew I was doing it wrong. I simply dont have the time to spend on this that I would like to. I can squeeze in some time here and there in the 'real world' aside of meetings and I'm enjoying getting to grips with MDT. I started with MDT2010 but have never really delved deep enough into it to take advantage of its full features. I'm only applying its uses on a small scale in small environments so I probably wont need to use every feature. However I do I have a 3 server and 4 client test rig at home (vms) which I use to practice on. I have been pointed in the right direction so yes, I have some reading ahead of me.
Working in small schools with low budgets, a lot of the software isnt deployable. There are no silent install commands and some of the software doesnt have MSIs. Some we even have to hack the code to get it to work.
You say ideally you would have one vanilla image that would go to all equipment. Suppose you had quite old legacy equipment that couldnt take 64 bit. Is it possible have one task sequence that would 'automatically' select x64 or x86? Thats would be handy.
Regards JH
It is possible to have 1 sequence deploy multiple OS's of multiple architectures - it does mean some hacking though which given where you are with MDT right now I would not recommend. SCCM can handle it seamlessly, but not MDT.
Your best bet is to make/test 1 sequence and when it's all working, duplicate it for the other architecture.
-
Friday, December 07, 2012 11:24 AM
Thanks, I thought as much given the tests I have run previously. So it looks like I will be narrowing it down to just four images as mentioned in a previous post. Quite happy with that. Now to allocate some time to practice.
We mostly see Samsung and Toshiba equipment in schools so I'll have to see if I can find a driver download manger for these manufacturers as well to easily get hold of what I need since the document I have only talks about HP and Lenovo. The toshiba model range in particular is mind boggling.
Thanks everyone for the advice!
Regards JH
- Edited by _Jonnie Friday, December 07, 2012 11:46 AM
-
Friday, December 07, 2012 3:07 PM
To be clear, you do need separate images for x86 and x64. These could actually be contained in the same WIM (WIMs can contain multiple images), but they must be separate images.
Saving you time is the whole of automation but if you don't take advantage of the automation features, that are there for you, then well, you only have yourself to blame. It's like using that hand-held screwdriver for the screws you are putting in instead of unwrapping the power drill and learning how to use it because it will take some time to learn how to use the new power drill and charge it up. That's somewhat valid if you only have 5 screws, but if you have hundreds, thousands, or more screws, it makes no sense.
Jason | http://blog.configmgrftw.com
.png)
