anyweb

Introduction Traditionally you deploy one operating system per task sequence but there are times when you might want to deploy more than operating system in the same task sequence. There are a variety of ways of doing this, for example you could use a MDT based User Driven Installation (UDI) task sequence which in turn requires you to use the UDI Wizard Designer to edit the Volume page and add, remove or re-order Operating System wim images which can then be displayed to the end user (shown below). This works well as long as you are willing to use UDI based task sequences and the associated UDI Designer Wizard and don't mind updating the MDT Toolkit Files package after doing so. Alternatively you could use a dynamic task sequence which uses a HTA FrontEnd (hypertext application or web page..) that is based on variables set in the task sequence itself. The HTA method is more dynamic as you do not need to update the MDT Toolkit files package every time you make a change to one of the operating systems included in the task sequence and you don't need to use a User Driven Installation based task sequence either. Here is what the FrontEnd looks like you can click on the drop down menus to select from the Operating Systems that you make available In addition you can use tooltips (by hovering over a drop down menu) in this task sequence to display helpful info to the end user about what each operating system is for. So how is it done ? I'll show you. Step 1. Get the Task Sequence Download the Multiple Operating Systems in a Task Sequence below. Multi-Image task sequence.zip You need to import it into your Configuration Manager server. To Import it, in the Configuration Manager console navigate to the Software Library and find the Operating Systems section, right click on Task Sequences and choose Import Task Sequence as shown below. browse to the UNC path where you downloaded the ZIP file above click next, you will get an import failure for the boot wim, select Ignore Dependency as shown below The task sequence is imported successfully. Step 2. Get the HTA Download the Multi Image HTA below Multi-Image.zip Unzip these files and copy them to a folder on your Configuration Manager server. Next, create a package by doing as follows, select Application Management in software Library, and choose Packages, right click and choose Create Package fill in some info about the package, call it Multi-Image Select do not create a program continue through the wizard until done Step 3. Distribute the package Right click on the Multi-Image package and choose Distribute Content, distribute it to all your distribution points as shown below continue until the wizard is complete. Step 4. Edit the Task sequence Right click on the Multiple Operating Systems in a Task Sequence task sequence and choose edit, you'll probably see the error below, it's ok we are going to add that package next... On the Display HTA step, click on the Browse button beside Package, and select the Multi-Image so it looks like below Once done, take a look at the three OSName variables, they are what is shown to the end user in the Multi-Image HTA. You can set these variables to match whatever three (or two or more) operating systems you are deploying in this task seqence. in addition you can define the two tooltips used in the HTA If you want the HTA to display make/model and serial number info then add a MDT Toolkit Files step, immediately followed by a MDT Gather step as shown below (this is optional, and requires MDT Integration with Configuration Manager 2012.) Now you need to add your operating system images, under the New Computer Group,click add,choose images and then apply operating system image as shown below click on browse and browse to your selected operating system image Next, select the Options tab, and add a condition (Task Sequence Variable) and enter the following info, ImageValue = OSValue1 as shown below repeat the above for each Operating System Image you want to deploy, however set the options value for the variable ImageValue to OSValue2 or OSValue3 as appropriate. You don't need to make all three available, you can simply disable one or two in the task sequence if you want and they won't appear in the HTA. Dynamic ! for the purpose of this task sequence, you can go ahead and add a boot wim and then deploy it for testing, obviously you'll want to customize the task sequence to do all the actions you normally do, below you can see that the second Operating System image was selected (OSValue2) and is being deployed as logged in SMSTS.log That's it, job done ! Summary Deploying multiple operating systems with Configuration Manager 2012 R2 is easy enough and there are many ways of doing it, this method is dynamic and I hope you try it out !. Related Reading CM12 in a lab - Part 16. Integrating MDT 2012 with Configuration Manager 2012 CM12 in a lab - Part 17. Using MDT 2012 with Configuration Manager 2012 CM12 in a lab - Part 18. Deploying a UDI Client Task Sequence Downloads You can download a Microsoft Word copy of this guide here. Multiple Wim Images in One Task Sequence.zip

i'll do a blog post on it shortly, so please wait.

you could simply add the logic for two task sequences into one task sequence (containing two operating system images), that would be the way I'd do it, and use something like the attached to pick your image/os download the files for that here Multi-Image.zip

great, do let me know how it goes for you !

can you attach the smsts.log file please

to not enforce a deadline you'd have to deploy your updates one by one or as members of a software update group and make the deployment Available, that way, the user is never forced to isntall any update, however that kind of defeats the purpose of installing updates (which are to keep your computers secure) so going back to your problem, are you computers installing updates at the deadline or not ?

simply create a package with no program, the package should contain your powershell script, distribute the package to your distribution points. once done, you can create a Run PowerShell Script step in your task sequence, like so the Package should refer to the package you created above the script name is the actual powershell script, eg path\to\myscript.ps1 and the parameters are whatever parameters the powershell script expects to be provided such as variables %somevariable% the Powershell execution policy should be set to Bypass (unless you've signed the script yourself) below is a sample powershell script being run in a task sequence

see my reply in the other thread, simply use what method works best for your environment

there is no best way, one way has certain requirements and the other method has it's own requirements, there are many ways to install the client it's up to you to decide which methods are best applicable in your environment, many use client push but it's one of the most difficult methods to get working (firewall, local admin rights issues etc)

The Client is on the same subnet as the ESX host as the SCCM server what network drivers are you using for the Configuration Manager server NIC

in my Lab environment, both CAS and PRI are running on the same port 4022 as shown below, is this also a lab environment you've setup, if not, why did you install a CAS ? CAS Primary

by enforcing a Deadline, you are forcing the installation of Updates which in some cases can cause reboots (if the updates themselves require a reboot) to be completed before the deadline is reached, you cannot set a deadline of 0 days, you didn't say if your ADR configured for Client Local Time or UTC ? same goes for your maintenance window settings there are three things that cause the system restart window you are seeing deployment notification is enabled for the client user notification is not set to 'hide in software center and all notification' an installed update (or updates) requires a reboot are you sure your maintenance windows are configured correctly and that the client computer is not in another collection with different maintenance windows ?

great stuff Lionel, for the benefit of others coming to this thread, please share with them how you determined the clients were getting their updates from WSUS

well it sounds like the clients are using WSUS or the Internet to download their updates, have you verified any of the settings in your Software Update Collections, for example add some virtual machines to those collections and test deploying updates to them, what happens (if anything)

thanks Garth !

if you want Software Updates to install after hours then use Maintenance Windows, right click on your respective Software Updates collection and choose maintenance windows, you could configure a schedule something like this... make sure your computers are in this collection (and if they are in any other that also has software updates deployed to it check the schedule/maintenance windows on that collection) and they should deploy the updates during the maintenance window, you may also want to configure notification settings, and basically deploy your SUG (software update group) to this collection, then TEST it ! cheers niall

welcome to the forums ! good to have you onboard :-)

you mean via the GetComputerName webservice ? what does the GetComputerName.log file tell you (in x:\windows\temp\SMSTSLOG\) when the HTA is displaying...

Introduction I've seen this quite a bit so I thought I might as well post it in case others see the same problem, what happens is that computers (virtual or real) that have an incorrect date in the BIOS will cause Policy retrieval problems during PXE boot. Problem Failure to retrieve policy means you cannot run any task sequence and the failure will in turn produce an error just before running any Required (Mandatory) task sequence or before displaying a list of one or more Available (optional) task sequences. Note: The error produced occurs immediately after entering the PXE password if one is set. The error message displayed to the end user is shown below, in the example below the DATE was set to one year earlier than the current date: and the actual error message shown using CMTrace in red text in the SMSTS.LOG file found in x:\windows\temp\smstslog is shown below and the text of the error message contained in SMSTS.LOG will appear something like the below Solution Well the fix is easy enough, simply set the correct date in the bios and then reboot the client computer and PXE boot again, this time it should not get the error noted above and it should receive policy correctly. While the above is an easy fix if it's a rare event you might want to automate a solution if you deal with imaging a lot of computers. So here's a method I've created to do just that, it uses the prestart ability to run a script in WinPE to sync time using NET TIME with a server you specify in your domain, it does require domain user credentials but you can decide how to deal with that. So Let's get started... Step 1. Download the following script WinPE_timesync.zip Copy this script somewhere useful on your ConfigMgr server, once done open it in notepad and configure the following section before continuing, save your changes Step 2. Add a prestart command to your boot wim Locate a boot image that you are using in your Task Sequences, and right click it, choose properties. click on the Customization tab and place a checkmark in Enable Prestart Command as in the screenshot below, enter the following in the box provided cscript.exe WinPE_TimeSync.vbs Next, place a checkmark in the Include files for the prestart command and click on browse, then browse to the network share where the script downloaded above is stored as shown in the screenshot below Apply the changes above, and answer yes when prompted as shown below Click next when prompted and continue through that wizard to completion. Step 3. Test PXE boot Using a computer that has the bios DATE deliberately set incorrectly (like 05-05-05) PXE boot the computer. If you only have access to a virtual machine such as hyperV then PXE boot and before entering the PXE password press F8, then type Date and enter the date 05-05-05. Note: Please make sure that the last deployed task sequence contain the boot image used above otherwise this prestart won't be used. You can do this by right clicking on the last deployed task sequence and verify what boot image is listed in the Advanced tab like below. Once done, PXE boot the computer with that you plan on testing with. If it's a virtual machine like mine, press F8 and type date to set the date to something incorrect like 05-05-05 as shown below Note: Without the prestart command and script provided here, the above date would be enough to produce the problem mentioned at the start of this guide ! Now you are ready to enter the PXE password, so go ahead and enter it, then press next, if you did the above correctly the prestart will pop up a command prompt window before running the script After a while, you'll see the list of task sequences displayed even though the computer had an incorrect BIOS date, now that is a result, no reboot needed ! So how does it all work ? well the script makes a connection to the specified server using a domain user, once this completes successfully (and it's required), we use a NET TIME command to sync the bios DATE/TIME with that on the server specified. You can see this in action by reviewing the SMSTS.log in CMTRACE In the screenshot below we see the first command prompt we opened to forcefully change the date manually. Notice how the logging jumps from the real date/time to 2005, that's the incorrect date now in 'action'. scroll down a bit until you see it executing the prestart command as shown in the screenshot below, notice how before the prestart the date is 05-05-2005 but after it's changed to the correct date and that the date change correction occurs before the Management point is contacted the rest of the smsts.log file will look like any normal one processing and downloading policy before displaying the list of task sequences, this would not be possible without the fix above. job done ! Troubleshooting The script generates three log files listed below WinPE_TimeSync.log WinPE_Net_Use.log WinPE_Net_Time.log please refer to these logs when troubleshooting non-working scenarios, for comparison purposes you can see what my successful log files look like below: WinPE_TimeSync.log WinPE_Net_Use.log WinPE_Net_Time.log Also to note, the script outputs the net use and net time commands to the CMD prompt window (for troubleshooting), but you can REM those lines out by changing any line that begins with: wscript.echo strCommand to 'wscript.echo strCommand cheers niall Related Reading http://www.windowsnetworking.com/kbase/WindowsTips/Windows7/AdminTips/Miscellaneous/HowtosynctimeinWindowsPE.html http://stackoverflow.com/questions/4121679/error-1219-occurs-when-i-try-to-map-a-network-drive-multiple-server You can download a Microsoft Word copy of this guide here. How can I sync the BIOS date in WinPE to avoid PXE boot failure with System Center 2012 R2 Configuration Manager .zip

personally i'd recommend you keep a backup of the current one and just import the new R2 one, there are quite a few changes to it and I don't have specifics on what those changes are, sorry. what error message do you see in the smsts.log when it bombs out ?

You talked, we listened... The world of IT and enterprise development and your needs are rapidly changing. In a cloud first, mobile first world you need: The broadest range of learning opportunities across the breadth of Microsoft's technologies and solutions Technical education, product evaluation and deep hands-on learning to plan, architect, deploy, manage, and secure a connected enterprise More access to senior technology leaders and engineers doing coding every day to get your questions answered A greater understanding of future technology vision and roadmap to help you be successful Greater community interaction with technology professionals and your industry peers in structured and informal settings Epic after hour gatherings where you can unwind and turn on the fun with your peers! We're excited to announce the inaugural unified Microsoft commercial technology event the week of May 4, 2015. If you've attended TechEd or Microsoft Management Summit, this is the place for you to be. It's everything you've come to know and love and more. You'll find what you're familiar with and you'll learn more about Lync, Microsoft Azure, Microsoft Exchange, Office 365, Project, SharePoint, SQL Server, System Center, Visio, Visual Studio, Windows, Windows Intune, Windows Server and lots more. Save the week of May 4, 2015. We'll be back in September with more details. See you in Chicago for this unparalleled event. Follow TechEd on Facebook, Twitter and subscribe to the TechEd Insiders Newsletter for event updates. This change only affects events scheduled in calendar year 2015. This year, TechEd Europe in Barcelona 28-31 October, will proceed as planned. To be clear, TechEd lives on. This event will be a part of and an enhancement of TechEd, co locating with that event to ensure the world of IT gets optimal access to all of the best resources in one place. via > http://channel9.msdn.com/Blogs/TechEd/SavetheDateMay4#fbid=&source=windows-noob.com

see the link i posted above, there's no simple way to do a refresh as it involves capturing users data either locally (hardlinking) or using a remote store (state migration point) before wiping the hard disc and installing the OS then restoring the data.

so you are installing SQL remotely yes ?

I think that since Satya Nadella joined Microsoft that we are seeing many changes to the company that were 'a long time coming' and that it's evolving far faster than it has in years. While the news is troublesome and awful for those who are loosing their job, I think it's for the best for Microsoft's future and I for one am very interested to see what is coming next

I haven't checked this HTA for a while now as it's based on Configuration Manager 2007, I have a Configuration Manager 2012 version of this task sequence below CM12 in a Lab - The CM12 BitLocker FrontEnd HTA - video CM12 in a Lab - The CM12 BitLocker FrontEnd HTA which does indeed partition a blank hdd when needed in the following group so, are you using CM12 or CM07 ?