Search the Community
Showing results for tags 'virtual machine'.
Ok so here is the situation. I haven't purchased the License yet to this service because I wanted to make sure that it would work, so I took an old computer i7 2nd gen, 12 gb ram, stock intel board. I installed Server 2012R2 (ill refer to this as host from now on) and then installed the Hyper-V role and created another windows server 2012r2 (SmartDeploySrv) image and I also made my reference machines on the host. It has all worked super smooth until now. I was able to make the reference machine and capture their image and download the ppk for the machine and I even configured it with WDS and can PXE boot to the WIN PE. Now I have tried to add the network share booting from the flash drive and also PXE boot. Both times I had a valid IP address in the corner and when I go to add the share I get Error 67. I have the right credentials. I am not in a domain so the creds are local credentials for the SmartDeploySrv. I got it to work with the offline installer and that is fine but I don't want to have to create a new flash drive every time i want to image a different machine, so I know it is not an issue with the machine. Any Ideas or suggestions would be appreciated.
In almost ten years of Windows Operation System image deployment experience, I have been chasing an easier way to manage the OS image development process or OS image life cycle. Most of us in the industry have grown tired of the antiquated process of building a reference Operating System image on driver specific hardware only to have the dreaded Blue Screen of Death (BSOD) appear when the manufacturer changes chipsets or other components on common corporate-class models. Many organizations have been tied to a specific make and model of computer for all of their employees. This over-standardization is hampered by long and often delayed computer refreshes which are driven by keeping the computers 'the same' to simplify OS image administration. IT Professionals can agree on the varying level of negative outcomes that they have experienced when trying to make their newly 'minted' standard corporate OS image work on different hardware that just arrived from the vendor who conveniently changed chipsets unannounced. IT offices everywhere have been forced to maintain dozens of copies of the same basic corporate image because of hardware component differences, device driver inconsistencies, and the beloved out-of-warranty computer models that are still supported within every organization. Then....along came virtualization. Several years ago, I started experimenting with VMWare Workstation to test scripted application installs with Windows XP. The beauty of a virtual machine (VM) resides in the ability to take a snapshot of the any current 'state' of the VM before you apply changes to the OS image such as an application install. For the first time, I could easily test and re-test changes to the OS image without having to re-image my computer or delete the Windows user profile in order to un-do system modifications. My initial excitement around virtualization was placed in the time that I would save, no longer needing to re-image computers for testing. Instead, utilizing a virtual environment for testing scripted applications and undoing OS image changes by easily reverting to a clean ‘snapshot’ of my VM reference computer. My thinking easily expanded to comprehend the advantages of using desktop virtualization for the entire OS image life cycle from beginning to end. For example, Microsoft's SYSPREP process is notorious for requiring a rigorous testing of the logic in an unattended file. By using virtualization technology to develop the reference computer image, IT Professionals can easily capture a 'snapshot' of the pre SYSPREP state of a VM for rapid testing while avoiding time consuming physical machine re-images and image re-captures that would normally be required during the SYSPREP testing phase. Now my only roadblock was finding a product that supported Virtual Machine OS image capture and coordinated OS image deployment to physical machines. First, I tested Norton Ghost to capture the VM of my sypreped reference computer image by booting the machine into a Ghost PXE environment, capturing the image, and storing it on the network. However, when I tried to apply the image to a physical disk it failed at boot with the dreaded Blue Screen of Death (BSOD). I realized my folly: my images would always fail to transcend the virtual to physical deployment process unless I could manipulate the device drivers for specific hardware. Fortunately, I had been following the development of an upcoming trial release of SmartDeploy Enterprise which heralded a new driver injection process that could avoid BSODs by managing device drivers as a package called a platform pack (collection of drivers). So, I captured an image of my reference computer image by booting the machine into a SmartDeploy PXE environment, capturing the image, and storing it on the network. Then I booted my Dell Latitude with the SmartDeploy PXE media, launched the deployment wizard, selected the captured image file, selected the platform pack for my Dell Latitude, and deployed the image. For the first time ever, I had successfully captured a virtual machine of a reference computer image and deployed that image to a physical computer which booted correctly with no Blue Screen of Death (BSOD). Furthermore, the Windows device manager looks clean with plug-n-play detection working seamlessly with the pre-compiled drivers from the SmartDeploy Platform Pack were injected correctly during the imaging process. Aaron Lines Email me IT Consultant