AkumaUk

Hmm, So, I've disabled and re-enabled the support command prompt (Updating the DP each time) and that didnt change anything. So I re-imported the original boot images (%program files%\Microsoft Configuation Manager\OSD\Boot Images\.." and tried using those instead. Still no luck. F8 is working as I can access the 'Additional Boot Options' menu when I boot a system, but not when I'm booting in WinPE through SCCM2012. I'm not sure what to try next

Hi Anyweb, Yeah, I'm definitley using this Boot Image, (I've deleted the original ones) so only have 32 & 64bit MDT boot images, both configured the same way. I'm going to change some settings and try again, will let you know what I find.

I'm creating a Windows 7 reference build using SCCM 2012 and all seems to be working well. I've noticed however that during the phase "Initializing the System Center Configuration Manager 2012 Client" phase it takes about 20 minutes to install and configure the client. The rest of the process works as expected with the actual OS being downloaded and applied in less that 10 minutes. Has anyone else noticed this? I'm going to attempt to 'troubleshoot' but for some reason, despite me selecting 'Enable command support (testing only)' in my boot images, its not letting me access the command line. I'm using MDT2012 Beta 1, so that might be the issue with the command prompt, but I doubt it. Any advice welcome!

I'm starting to use SCCM 2012 and have to say I'm really impressed. There are a few things that really bug me, and one of those has presented me with an issue I'd like some advice on. SCCM2012 uses 'Applications' rather than packages to deliver content to a user or device based on certain circumstances, which is very useful. However, 'Applications' only understand apps that are installed via .MSI files, App-V files, etc. You can't use .exe files. And this is where it comes unstuck, because as we know, the best way to install Office 2010 is to use "setup.exe /adminfile.. /config.." So my question is do I: A: Create a 'Package' (old method) and use that for deploying Office during OSD AND also to Users when required B: Create a 'Package' for OSD AND an 'Application' for Users/Devices (from App-V package, perhaps?) C: Another method I haven't considered? What's the general consensus? Thanks!

I'm not 100% it is logged anywhere, I can't test at the moment, but there are two places I would look: In the SCCM Console, Site Status > State Message Queries > All Status Messages and then set a time range for the required logs. Outside of the SCCM console, try having a look in the AdminUi.log in 'Program Files\Microsoft Configuration Manager\AdminUi\Logs' and see if that has anything. Please let us know if you find anything!

Are you talking about migrating .PST files? I was trying to do this recently at a customer site and ran out of time. I'd love to know if anyone else has managed this. A users .PST files are migrated by default, but they don't get associated back with the users accounts when they log into Outlook 2010. Is this possible, or is it a manual step afterwards?

Bu7ch, You can create an SCCM task sequence to to capture user data to a central location or State Migration Points, which will run in the background with little impact. There are standard SCCM/MDT task sequences to help you. However: There are lots of considerations to this approach unfortunately. The first is you need to create the computer association in SCCM BEFORE you run the capture script if you want to use SCCM SMPs, which can be painful. Secondly, if you run the Capture task sequence, how much time will have passed/what will have changed before you deploy the new system? In a replace scenarios (which is what you're talking about, refresh is to rebuild the current machine) it's very difficult to co-ordinate the capture/replace of data when the user is remote. If you plan to send them the new laptop rather than visit, the only real thing you can do is communicate that documents & settings changed after X date will be lost unless stored somewhere on the network. Otherwise, if a visit is possible, having a USB stick with USMT on it (with scripts or a batch file) can be used to 'quickly' migrate data between two machines. It depends on the numbers you're talking about and the amount of local data you want to transfer as to which is more acceptable.

Haha, why yes I do! Feel free to add me as a friend on live and we'll get some games in. I've finished the campaign once, am going through it again (with my brother this time) and am also really enjoying the new Horde mode.. the tactics side of things is excellent.

Tjddx, If I understand you correctly, you want to be able to apply an operating system based on collection membership, but using only one task sequence? I would create two (or more) collections called XP Builds & Win7 Builds and give them a Collection Variable 'DESIREDOSTYPE' with a value of 'WINXP' or 'WIN7' depending on the collection. This technet article should help: http://technet.microsoft.com/en-us/library/bb680526.aspx Then in my task sequence I would have two steps, one to deploy my XP image and one to deploy my Win7 image, both configured with the conditon 'Task Sequence Variable' 'is Equal to' either 'WINXP' or 'WIN7' as appropriate. Using this method means you can also add or remove other steps (software or drivers for example) using the same method, When you add a computer to SCCM with the import computer wizard, you can specify the collection to be added to, as desired. Personally though, I would have two seperate task sequences (cloned as neccesary) with two adverts pointing to two seperate collections. But that's just me!

Bronx Bull is correct.. In your task sequence steps for capture and restore you should have either: MigApp.xml & MigUser.xml OR MigApp.xml & MigDocs.xml (You cant use User & Docs together). Additional xml files, such as printers or wallpaper can also be added. You can't add a Config.xml file in my experience though, as it needs a seperate command /config:<filename.xml> rather than /i:<filename.xml> so if you want to use a Config.xml as well it needs to be added to the task sequence variable OSDMigrateAdditionalCaptureOptions in a seperate step.

I would be more inclined to create a reference image from a Windows 7 build with integrated SP1, rather than install it as part of a task sequence. You can download Windows 7 SP1 from the Microsoft Partner website. If you already have a WIM file that you want to keep using unfortunatley its not supported to use the dism tool to inject SP1 into your WIM, but you could use the standard two stage reference build process in SCCM to build from your existing WIM, apply SP1 manually and then capture the WIM for use in the production environment. I'd suggest there's something not right with your MSI, but if you want to install from the .exe you can use windows6.1-KB976932-X86.exe /unattend /nodialog Using windows6.1-KB976932-X86.exe /? from a command prompt will give you all available options. Hope this helps!

Excellent! Good to hear you got it working.

Hey Bronx, Did you get this sorted in the end? If so, what was the issue? If not, where are you still stuck? Maybe we can help!

Hi Julius, I'm afraid we're going to need a lot more information than that to help you! Firstly, if you're trying to run the same task seqeunce again on Tuesdays PC through a mandatory advert, then I'm afraid it won't ever run as its already completed successfully. If you change the advert to not be assigned (ie not mandatory) or 'Allow user to run the program independently of assignments' you can then manually run the Task sequence again from the 'Run Advertised Programs' control panel applet. See http://technet.micro...y/cc180264.aspx for more info. As for why the second PC (Wednesday) didn't run until much later, or complete the USMT parts,it is impossible to say without more information I'm afraid. What does the task sequence report say?