Mikey C

Think i might have answer my own question here. First read this post: http://social.technet.microsoft.com/Forums/systemcenter/en-US/11b77508-1096-4e8e-a437-6d1ddc3fc224/downloading-mdt-toolkit-in-osd-task-sequence-takes-forever As I knew the MDT Toolkit package is basically a file copy, but the important bit is that it then creates some smsts variables for the resultant folders which are mentioned above. I have confirmed the names of the variables by running a script to dump the task sequence variables to a text file and comparing before and after the MDT Toolkit step. These are the relevant differences: DeployRoot = C:\_SMSTaskSequence\WDPackage ResourceRoot = C:\_SMSTaskSequence\WDPackage ScriptRoot = C:\_SMSTaskSequence\WDPackage\Scripts ToolRoot = C:\_SMSTaskSequence\WDPackage\Tools\X64 So if i add four steps into the TS to set the four TS Variables above, then set the self extracting rar file to extract to C:\_SMSTaskSequence\WDPackage (or %OSDisk%\_SMSTaskSequence\WDPackage would be better), I may have account for everything the MDT Toolkit package does. Will try, and post back.

Our method is more efficient than anyweb's, although the same command. 1) Map a drive to a network folder containing the appropriate sxs folder for the OS version and CPU architecture, and using credentials that have access to the folder (note that the sxs folder contents will almost certainly change with the release of Windows 8.1 in October). This saves a little hard drive space and uses only required bandwidth on the next step. 2) Run the command using the above mapped drive, so for us it is: DISM.exe /online /enable-feature /featurename:NetFX3 /All /Source:N:\ /LimitAccess /NoRestart /quiet We use this in our Capture task sequences, to speed up the Deploy task sequences.

Out of interest, are you running SCCM 2012 SP1 with CU2? Did you upgrade to SP1 or installed from the start? These two posts may be of help: http://social.technet.microsoft.com/Forums/en-US/221bcfe8-4c1e-4766-be5b-fbf54fe0e66c/specific-model-suddenly-fails-on-any-application-install-packages-work-fine This is kind of a summary of the above post http://ericsccm2012.blogspot.co.uk/2013/04/applications-fail-to-install-on-ssd.html This is a similar problem, but different proposed fix http://social.technet.microsoft.com/Forums/en-US/923a57b1-2107-41dd-abc5-e387325ae166/occasional-task-sequence-fail-1-out-of-5-with-error-615-your-password-is-too-short

We have MDT integrated with our SCCM 2012 SP1 CU2. We use the MDT Gather step to determine whether devices are laptops or desktops and it works fine. However, on some slower hardware, slower network links, or a congested network, the MDT Toolkit Package step takes an annoyingly long time as it contains quite a large number of small files (it is not the volume of data, its the number of files that slows the process). Our task sequence works great, but I would like to reduce the 2/3 minutes that this step takes. Therefore, I would like to replicate with a simple self extracting zip file (which will also reduce the package from 50mb to 14mb. But, i need to know where to extract the files to, so that the MDT Gather step which runs right after will work. Can anyone advise how to do this? Thanks.

Yes we are - Pressure from SMT really (shiney new toys please, make them work sysadmin b1tch!) So, we have deployed Lenovo Tablet 2, Microsoft Surface Pro and Lenovo Helix. First things first: Tablet 2 only supports 32-bit EFI - therefore, cannot boot from any other media (WinPE3 for example). This highlights a significant problem with SCCM boot media, that doesnt seem well documented: when you have created a boot media ISO in 2012 (WinPE4), it does not contain the required .efi to boot from USB. You must manually create a bootable pendrive (FAT32 only for EFI) and then copy the files \efi\boot\bootx64.efi for your x64 boot media and \efi\boot\bootia32.efi for x86 boot media. You can find these files on any Windows 8 ISOs. Of course you must add the x86 and x64 USB to ethernet drivers to the respective boot media. As far as PXE is concerned, we have not resigned the 2007 PXE and replaced it with 2012 PXE (cant coexist on same subnets easily, and not at all on other subnets due to the limitations of the IP helpers setup on routers) so my experience is limited - We have built all our machines using USB boot media, it worked without issues once the pen drives were setup correct*. But from my home lab; firstly the USB ethernet device MUST support EFI PXE, not just old style BIOS (?) PXE. I dont think that all do. Other than that, i think it should just work (i hate it when people say that!). If you have had any specific PXE issues, let me know and i might be able to help. * A really useful tip for the USB boot media (might be obvious to some of you!!), is create a folder and stick the contents from all your ISO's in sub folders, then all you need to do is move the files to the root when you want to use those boot files, and obviously move existing ones back to their subfolder when not needed (so you dont overwrite). Saves repeated copying the files from PC each time you want to switch from x86 to x64 boot media.

Peter - What credentials will be used to connect to the network share?? During this step? If this is a build and capture TS and therefore the PC is not on the domain, and with no ability to specify credentials, I do not see how a network share could be accessed.

I spent ages on this problem, so i thought I would post and hopefully help others. Thats because if you setup the USB drive using diskpart, then copy over the contents of the Boot Media ISO, you will NOT have the CRUCIAL EFI files to boot from. Therefore, make sure the following folder\files are present (you can search for the files in the ADK folder). For 32-bit devices x:\Boot\efi\bootia32.efi For 64-bit devices x:\Boot\efi\bootx64.efi Without these files, in the folder structure indicated, the device will not boot. There seems to be little documentation to tell people of this. Presumably when you create a generic WinPE4 device following the many guides around, the above files are copied. But for some reason, creating SCCM boot media does not copy them, despite them being essential in order to boot. Hope this helps.

You would have been better attaching them than posting! If you attach them they can be opened in trace32 whcih is easier to see and search for error messages etc. Have you checked all the basics: Advertised the updates to a collection the server is a member of? Is there a maintanence window preventing the updates installing (or ticked the ignore maintenance windows tick box)? Are the updates packaged on a DP whcih is available to the server (ie is there a boundary issue)? Do you have any GPOs on servers whcih might affect the WSUS settings, differently to client machines?

I cant beleive i will be the only person asking questions about the release of this hotfix, so thought i would start a new thread. Obviously, first we need to install the hotfix on all the servers, including the server hosting the sms provider (which is the SQL box in our case). 1) Do I need to install it on all machines with the just the console installed, or just Win 8 computers with the console installed? 2) Do I need to deploy the fix to all devices, or just Windoes 8 ones? There doesnt appear to be a mif file in the hotfix like with KB977384, does that mean that the ccmexec service is not restarted as part of the client install? 3) Do i need to add this hotfix into task sequences PATCH= for all devices or just Windows 8 machines? The hotfix also seems to address an issues which is not documented as being Win 8 related: "When the system processes a new power profile, the SMS Agent Host service (Ccmexec.exe) or the WMI Provider Host service (Wmiprvse.exe) stops unexpectedly." Can anyone ellaborate on that - Is this hotfix recommended for anyone who has no plans to impliment Windows 8 (but who experiences that issue)? If so, do they need to do any of the above?

Whoop!

Also, do you have the Site Maintanence Task 'Client Install Flag' enabled?

If you have a dev/test environment - Why not try approving the Windows 8 updates in WSUS and seeing what happens to SU. It would be interesting to see what happens. I expect that the Win 8 machines will update wirthout issue, its whether the SUP has issues as its not supported by MS to make any changes via the WSUS console when its linked to SCCM.

Hi. Cannot see your smsts.log which would be required to help further i think - i dont recognise that error message.

If you want the SCCM client to inventory that key, this is the page that contains all the information you need to edit your sms_def.mof http://www.myitforum.com/myitwiki/SCCMINV.ashx That may be a bit drastic for a one off key though! how about something along the lines of reg query HKEY_Local_Machine\Software\Policies\Microsoft\SystemCertificates\Root\Certificates > \\server\share\%computername%filename.txt

1) I prefer InstEd-It to Orca (which is difficult to obtain) http://www.instedit.com/ There is a great free version too. 2) Also, have you thought about using a task sequence to run the different command lines one after another, rather than a batch file? Might have an impact on the command line being interfered with (if that is what is happening) 3) And I would ALWAYS get msi installs and bootstrap installers to generate a log file in everycase. We have created a suitable folder on every machine in our envinronment and use that path for all SD log files, so any member of ICT staff can pole around if there are issues. Hope this helps.

I recently added a number of additional bits of info into the inventory, by editnig the sms_def.mof. All the changes were documented here, the edits were all done very carefully, and the status in the dataldr.log showed that the changes were succesful (i cannot post the dataldr.log here because the file has rolled over and only shows from 13:00 today... how can i keep more logs!?). Most of the changes that i had implimented had worked, including some more custom ones. However, the most simple change of all is not showing in resource explorer nor is it available in collections/queries/reports. The problem is with Win32_ComputerSystemProduct - All I did was change the top level from FALSE to TRUE and also to enable UUID, Name, Vendor, Version. On client machines, i can see in the inventoryagent.log the following line (whcih was not appearing before the changes to the sms_def.mof and refreshing machine policy etc.) Collection: Namespace = [url="file://\\.\root\cimv2"]\\.\root\cimv2[/url]; Query = SELECT __CLASS, __PATH, __RELPATH, UUID, Name, Vendor, Version FROM Win32_ComputerSystemProduct; Timeout = 600 secs) which completes in an instant, so no reason to suspect there is an issue locally either. Can someone tell me why this class not showing in resource explorer/collections/queries/reports?

Thanks extremely helpful, thanks Peter I had already leveraged the additional data actually, but hadn't found out what each number had indicated.

It is incredibly annoying that every here have suggested very drastic fixes, such as site resets, create new certs etc. We are experiencing this problem ONLY on XenCenter. The boot images work fine on everything else. PXE works fine on everything else. Works fine on VSphere, works fine on VirtualBox, works fine on hype-v, works fine on physical machines. I have confirmed the time in the Xencenter VM is correct, the date is correct so doesnt seem to be cert related (no error message indicating cert issue). The error message we receive is identical to this one http://777notes.wordpress.com/2012/10/09/sccm-2012-failed-to-get-client-identity-80004005/ - but the time and date are correct (its NOT A PHYSICAL MACHINE!!! Cant change the BIOS time/date). This is soo frustrating!!!! Also, when pressing F8 to open a dos window, we cannot map drives "system error 64 has occurred The specified network name is no longer available". I have recreated the boot images using the very latest (different) NIC drivers, so i am convinced its nothing to do with that. What a major PITA.

hi garth thats an interesting comment - i had no idea that was recorded in WMI. I dont suppose you could tell me the alias/command to display that information in a dos window? Something along the lines of wmic csproduct get That way we could test to see how many of our devices actually report this in WMI before editing that file.

I agree with Peter33 - Its not wise to reference the iss file from a network share - include it in the software package and reference it locally, with the obviously benefits of hash check and BITS transfer etc. (even though its a small file, its still good practice). Also related, and in response to what you have mentioned above, just because you have hosted the source for the SCCM package on a particular share (\\******\support$\SCCMDeploy\Cisco Ironport Plugin as you put it), does not mean that because the clients can download the package contents, that they can access that share using local system creds as part of an advertsied SD package. Remmeber, the clients will download the package content from \\server\smspgkx$ where server is your DP and X is the drive letter that the DP hosts the software on. Therefore, the share permissions on the \support$ and the \smspkgx$ could be different and in this case the error could be related to clients not being able to access the iss file using the unc path you have used. Finally, note that the variable %~dp0 will only work in a batch file - but you should commit it to memory as its very useful IMO. "Percent, squiggle, Dee Pee Zero" is how i have remembered it for the last decade or so! Hope this all helps.

In addition to specifying the boot image in the task sequence, SCCM will always use the boot image from the MOST RECENTLY ADVERTISED task sequence for PXE booting. Therefore, to ensure you are using boot image D, you should create a new advertisement referencing a task sequence which uses boot image D. I beleive you could even then delete that advertisement, but the site would still have that boot image referenced in WDS as the boot image (for that parrticular CPU architecture of course). There is no way to manually specify a particular boot image to be used to PXE boot if you have multiple. Its an oversite in SCCM in my view.

I referenced the Hydration kits, not as a solution for this post, but an example of thousands of people using a standard rtm Install.wim to successfully deploy an OS to the correct destination partition (which i presume you mean by "installed on a D: partition"). If the client hard disk only contains a single partition, then windows would not assign a drive letter D when installing. I think you are getting confused with installing an OS through the UI without manually create the destination partition using shift+F10, in that circumstance the OS installer automatically creates a hidden partition 0 of 100 mb (or more if you are using an EFI device) and then installs the OS to partition 1. In that case, all the boot files are on partition 0 and if you only capture partition 1 then you obviously are going to be missing all the boot files and the resulting OSD TS will not boot. However, simply applying an install.wim to a drive with only 1 partition causes no problems at all, and does not create any additional partitions (unless your task sequence does) and will boot fine. Hope this helps/clarifies

Setting DHCP options for PXE using SCCM 2007 is not supported by MS, you should only use IP helpers. When you say times out - is this timing out waiting for an IP from DHCP? This is not the correct behaviour from my experience.

Are you trying to create the accounts in WinPE!? Are you using 802.11 to access content to OSD? If you are trying to create local accounts in your client OS, you should add them into your unattend.xml and they will be created when installing/configuring Windows.

Just use it back to front! sorry, i couldnt resist!