At first I would have agreed with that thread, but then I thought about it for a moment. I used a second computer, that had been imaged with a fresh image from Ghost, to capture from. I then deployed out the image to the computer that I was deploying from previously. It is possible, that there might have been a MININT folder left over, but since the only thing I did on this system previously was capture for testing and deployed a different image, I don’t think that was the issue. This same issue occured previously when I deployed out the image to a few test desktops that had never been touched by OSD before. The difference there was I used the wrong sysprep.
we should still verify that \MININT does not exist on the captured WIM image.
To mount, use a computer that has WAIK insatlled, and run the following command:
imagex /mount d:\imaging\data.wim 1 c:\mounted_images (where 1 is the index of the image we’re interested in within the WIM file, we assume this to be index 1).
You should also make sure _SMSTSTaskSequence also does not exist
either
in the WIM or in the old operating system of the machine being re-imaged.
Existence of \MININT or \SMSTSTaskSequence will cause MDT to pick up where it thinks it left off, since these two temporary files/folders contain the state of a running MDT deployment.
The problem in this case is not apparent to me. There must be something that is missing - something not detailed in the logs.
Are there settings that get applied when a computer joins to your domain that might explain the behavior? In the second MAG, we do disable the Administrator account for windows 7 re-images.
Please re-attempt the re-image, re-ensuring that all is clean.
I assume yes, but did you capture the WIM using our dashboard - or was this a manual job? Along those lines, did you customize anything?
Another useful log will be the \SMSTSLog\smsts.log usually found in either c:\windows\temp or %temp%
I started to lab 8.2 with TPMfOSD. I have lot of experience of MS SCCM OSD.
I have some basic question of BigFix product regarding OSD technology. For now, I´ve already setup TEM 8.2 single server, upload the OSD .msi file, uploaded MDT bundle, got OSD health green of all parts and managed to deploy a refresh scennario with Win7.
How I can get my server to TEMfOSD server manager list? I can´t do that right now.
I need PXE boot for bare metal installation scennario (not refresh). How I get PXE working. DHCP option 66 is set to point my single TEM server.
How I should include additional software installations to a installation phase?
I have one original Task Sequence of Win7x64 in MDT. Should it stay untouched? If I do any changes to TS configuration, should I reload the bunlde to OS deployment setup?
Where/how I can configure, at what AD OU location the new computer account would be created?
It’s my understanding that there are two separate ways to perform OSD through TEM right now.
TEMfOSD
TPMfOSD
TEMfOSD can deploy an image to an existing TEM client, it doesn’t do Bare Metal installs. It is intended for upgrading WinXP systems to Win7.
TPMfOSD is essentially Tivoli Provisioning Manager with some TEM integration. This is the product that can perform the PXE based OS installs. It requires a TPM server be installed. TEM and TPM are in the process of being better integrated.
TEM and TPM are in the process of being better integrated.
Yep, I have TPMfOSD actually in place.
But you pointed out same thing, as what I was thinking - for me it seems very much that OSD in TEM isn´t ready as it should be. It would be nice to know some facts, what is currently the developement phases and when it should come out as entire product? Not just a “tag” between TEM management and MDT.
Wow, I installed TPM until the end, now I have PXE boot working which boots empty machine to a Tivoli OS Deployment enviroment. But it just stays there… how I should start new installation?
Just wanted to comment on the statement “It requires a TPM server be installed”.
Due to naming of the products from IBM, I know that these names have caused confusion so I will try to explain.
TPM - Tivoli Provisioning Manager is a server automation product that has a vast array of functions, one of them being that ability to provision an operating system. To provision the OS, TPM will take advantage of many different provisioning tools like kickstart and NIM. For Windows and Linux it can also use TPMfOSD. TPMfOSD is a separate tool that is included with TPM.
TPMfOSD is a standalone tool that provides baremetal OS provisioning. At a minimum, you will require one TPMfOSD server, but generally you would have a parent OSD server on a main site and then child servers located at remote sites or build centers. Typically you would connect with PXE, but it is also possible to create a boot CD to connect as PXE is not always available.
Currently, there is a site called “Client Manager for TPMfOSD” but its function is really limited, you still need to go into TPMfOSD to do the real work. Tim is correct that there is work under way to integration TPM into TEM.
I am not sure what you mean by “server manager list”. Also are you referring to TEMOSD or TPMfOSD? Seems to go between the two names and I just want to make sure
I think I saw that you have it working, so will not comment on this
You could use the Software Modules to post install (not in your image) any products and configurations. This is what you use to inject drivers to the system. You can also leverage TEM to deploy software with a baseline action that would target systems that are being built.
I would assume that it could, but no idea what it does. You could also move it to a software module or a TEM fixlet.
Go to System Profiles, click on the desired profile and on the bottom it will show “Configure <profile config name”. Click on the desired configuration which will take you to the “OS Configuration Details” screen. Then click on the “Windows” tab. Beside the “Windows-specific info” click the Edit button. Set the “Network type” to “Join a Windows domain…” and then the field “Active Directory Org Unit to join” will appear.
Thanks a lot guys for explaining, I´m starting to get an entire picture of this. I´m having difficulties to find exact step-by-step or best-practise guide how to do things with OSD in TEM. I got my empty client PXE booted to a lock screen, so somehow I need to push the image-installation there, but I can´t realize how. Also, PXE client from other IP scope doesn´t see PXE service, so I assume I need to set DHCP option 67, but what exactly? Similar situation I had with SCCM OSD, where a path to boot image needs to be set to DHCP, if booting from another IP scope than the main server resides.
Forgive me if I have not followed every post in this thread, as a lot of different questions get asked in this one thread. It would be helpful if all new questions or topics, get their own thread instead of all OSD questions being in this one incredibly long thread. I believe it will make it easier for people to find information and respond with appropriate named threads.
Anyways, to answer some of your questions, it looks like some of your confusion on how the products was cleared up. In summary we do have the TEM OSD product. Which as you’ve seen and gotten to work uses MDT and functions entirely through the TEM UI for re-imaging machines that already have a working version of Windows and the TEM agent.
We currently do not have any support for bare metal, and so that is where TPMfOSD comes in. It is not currently integreated in to our product. It is a standalone product and needs to be used and configured standalone. So referring to TPMfOSD documentation and help for issues there. We do provide the Client Manager for TPMfOSD site to help manage them in very simple cases, see what’s out there, install, upgrade, uninstall. We also can import RAD files that are provided. This is a way a user could have some control of what is in TPMfOSD servers distributed across their network. This is completely independent of the TEM OSD product however. We are working on integration that does much more what you’re thinking and is planned for later this year.
For the questions related to DHCP, we unfortunately offer no means for configuring or assisting configuring your network to support PXE. Sounds like you’re familiar with the issues you’re facing to get the endpoints to be able to see and contact the TPMfOSD servers when PXE booting. I’m no network administrator and I know each network will be different in what subnets you’ll need TPMfOSD on and how to configure DHCP so all endpoints that you want to see TPMfOSD can see it.
PXE across the subnets usually involves an IP helper. I know that this part is always fun to get working as it is not really something you control in TPMfOSD.
For the most part this process works, but with some of the newer versions of TPMfOSD (post FP6), there were some changes required with the Administrator account.
One other big difference between TPMfOSD and TEM OSD is how an image is captured. TPMfOSD can support the import of a WIM file that is prepared in MDT/WAIK, but you can also do a capture which is in a format specific to TPMfOSD. The advantage of the WIM file is that you could use this across almost any deployment tool. One of the main advantages of using the TPMfOSD capture is that it is stored in a way that allows for delta changes between different system profiles. What this means is that if you create one Win7 image and you import it into TPMfOSD, it will add a whole bunch of files to the shared repository (the whole Win7 image). If you then import another Win7 image, only the differences between the two images is imported. This means that the disk space usage should be smaller than using a WIM when you have multiple images.
As for the screen you are stuck at, I have seen that occur with some hardware types that usually involves making some adjustments to the hardware handling rules. When you are getting into that splash screen, press the ESC button and it should let you see what is going on. Sometimes it is clear as to what is hanging, sometimes not so much
Thank you for answars once again. I can see, that there is no sence to continue evaluating OSD now, because it is not ready from our point of view. I´m very intrested, what impovements are planned and when the entire solution will be released. Our organization is planning to move from SCCM to TEM.
I´ll try to explain what we actually need in our production life with workstation deployments and how we do things with SCCM today.
we don´t maintance .wim file. It contains only OS, nothing more. Same .wim is used in any scennario, with any customer. Some of configuration comes in answer file
during the computer installation process, we apply various software installation tasks, same packages and configuration as used in software deployment
enabling hard drive encryption (bitlocker) is automated during installation process
during computer installation process, is will be patched with recent MS patches via WSUS or SCCM SUS.
So as you can see, lot of integration between TEM and OS deployment should be made to make things work. Installation process should be entire, meaning that our installer guys around the country can´t wait after OS has been boot up, that all software will be dropped at some time with TEM´s baseline actions.
I am not sure what in that list you feel that TPMfOSD and TEM cannot do.
Here is a basic idea of what we are doing now.
TPMfOSD deploys Windows XP or Windows 7. This image is a fat image, but that part does not really matter much
With Software Modules we deploy the proper drivers for the hardware type. This is done automatically through binding rules
With Software Modules we deploy additional application software. We do not use bitlocker (use another encryption software), but we did use try it and were able to enable it with a software module. This additional software is usually critical software like encryption and antivirus.
System is then patched and remaining software deployed with TEM. This will usually take about 15 minutes to start from the time the agent is first started.
There is no real integration that is needed other than getting the agent on the target and then determining how you want to apply the baselines, and there are many ways to do this.
One issue you have to be careful with is the multiple deployment tools is that they could be installing at the same time and then the installer from one could fail out the installer for the other.
Now I do not know your full environment, if you are zero touch or lite touch and other requirements, so it is hard to just say that it will for sure work for you, bit I honestly do not see why it could not. Also without knowing, any other recommendations to give you
I know that IBM is working on the tight integration of TEM OSD and TPMfOSD for the end of this year.
I´m not yet familiar with Software Modules, does those resides at Tivoli OS Deployment or Tivoli Endpoint Management? I understand, that I could build a baseline containing full set of desired applications and deploy those right after new computer account would be generated in AD and will start talking to TEM server, but it will take some time when refreshing relevants etc. This also means, that a computer would start up at CTRL+ALT+DEL state before it would be entirely ready, right? Also, when deploying many software with baseline, can the installation order be controlled?
Currently, not seign OS Deployment installation yet, I see some challenges:
a person who will take a brand new machine from a pack, won´t have access to the TEM console. He somehow need to make sure, that installation is entire. With SCCM, it´s enough when seeing a entire installation process running before CTRL+ALT+DEL state. In some cases, these people are not so technically educated
some generic software packages needs to be installed in every computer during installation/deployment, using same packages which are located in TEM´s Software Distribution
during installation, a workstation needs to be fully patched with updates.
Sorry if repeating myself, I want make sure you get our challenges.
Software modules are built into TPMfOSD. With these modules you can put them in order and with reboots between different modules if required.
When using the software modules, you can also use binding rules that will automatically add the software modules to a system. These binding rules can be used to identify all kinds of properties of a system.
Patching would obviously be done from TEM, so you would create your baselines and have policy actions running.
One thing you may also want to look at are the boot menus in TPMfOSD. This will allow someone to boot with PXE/cd and then be presented with a list of system profiles to select.
Just configured my first System Profile. I liked that pop-up info for gathering information before installation
There is still one issue, and I hope it would be solved when developing a new version or “link” between TPMfOSD and TEM. Same software binaries and configuration should be used in OSD and in Software Distribution. I´m not seeing that our people would manually update and maintance software library in TPMfOSD’s software modules, after done every new package at TEM´s software distribution.
Another thing - I need to PXE boot work to other subnets. In SCCM, this was solved by adding a path to a boot image using DHCP option 67. From TPM install manual, I found a line Rembo-x64UEFI which is set to linux DHCP box, but I tried and it is not good with basic AD DHCP infrastructure. I need this to work. Any ideas?
