BB24

Would need to see some smsts.logs but are your certificates still valid? How are you actually getting the WinPE onto the client - PXE, Boot Media?

NightCD, In my environment I enable bitlocker after the OS is applied and after I join the domain. I don't know how you can save to AD without being part of the domain.

Are you joined to the domain before you provision?

We use a partial static and combine it with a randomly generated. Not sure that combination necessarily improves support/security though - using complete random is probably best.

CalleW, It hasn't been confirmed fully, but I think so. The key is not to use the built in Pre-Provision command (in the MDT menu) and to ensure that the following tpm states are set: IsOwned_Initial.Value = False IsActivated_InitialValue = True IsEnabled_Initial.Value = True (you can see these states from the F8/Debug prompt by running the wmic command) wmic /namespace:\\root\cimv2\security\microsofttpm path win32_tpm get * /format:list I was able to build a .vbs to check and change the IsActivated and IsEnabled values by using the SetPhysicalPresenceRequest method of the Win32_TPM class as described: http://msdn.microsoft.com/en-us/library/windows/desktop/aa376478(v=vs.85).aspx (It then requires a reboot on Dell, HP and Lenovos to accept the change (hence the SetPhysicalPresenceRequest....) but you can stage the image with a simple Restart TS step. I was not able to change the IsOwned value however without manually clearing the PIN in the BIOS first. After the states are set properly, I then run the command: manage-bde.exe -on -usedspaceonly %OS% (where %OS% is the volume where the OS is going to be applied) and then apply the Operating System. After joining the domain and setting my regkeys for the backup policies, I run the manage-bde.exe -tpm -o password command which then populates the msTPM-OwnerInformation field. Later on you can set the Bitlocker PIN as I wrote about earlier. Hope that makes sense.

I had problems with the utility working if I didn't set the password and then clear it. Didn't try it as a single line. File extension doesn't matter. .repset or .txt will work.

I haven't used the biosconfigutility64.exe but the previous version would not work in the Windows PE environment - has to be used after the OS was laid down. Partition Pre-provision OS Config Mgr BiosConfig - set BIOS (BiosConfigUtility.exe /setConfig:TPMEnableV2.REPSET /cspwd:"" /nspwd:"password" /verbose) BiosConfig - set BIOS (BiosConfigUtility.exe /cspwd:"password" /nspwd:"" /verbose) Restart Set 2 regkeys (backing up recovery key to AD) a) AD Backup (REG ADD "HKLM\Software\Policies\Microsoft\TPM" /v "ActiveDirectoryBackup" /t REG_DWORD /d 1 /f) Require AD Backup (REG ADD "HKLM\Software\Policies\Microsoft\TPM" /v "RequireActiveDirectoryBackup" /t REG_DWORD /d 1 /f) Take TPM Ownership (manage-bde.exe -tpm -o password) Set 4 regkeys (setting up a complex default PIN) a) Set Enhanced PIN if you want to use something other than a numeric PIN (REG ADD "HKLM\Software\Policies\Microsoft\FVE" /v "UseEnhancedPin" /t REG_DWORD /d 1 /f) Set Advanced Startup Policy (REG ADD "HKLM\Software\Policies\Microsoft\FVE" /v "UseAdvancedStartup" /t REG_DWORD /d 1 /f) c) Set TPM and PIN policy (REG ADD "HKLM\Software\Policies\Microsoft\FVE" /v "UseTPMPIN" /t REG_DWORD /d 1 /f) d) Set the default PIN (manage-bde.exe -protectors -add %OS% -TPMAndPIN c0mP!3Xpwd ) Be sure to suspend your bitlocker in the remaining parts of your TS before any additional reboots. (manage-bde.exe -protectors -disable c:)

Using this method, is anyone able to set the TPM Owner Password and save it to the AD Attribute msTPM-OwnerInformation? So far I haven't been able to do this as it seems that the Pre-Provision Bitlocker step takes ownership, but because it hasn't joined the domain, is unable to upload the TPM Owner password (speculating). I can confirm this by clearing the attribute value (currently hashed) and then running though the Task Sequence steps. The result is a fully encrypted system, TPM is active, TPM is Enabled and the TPM is owned, but I don't know that the TPM owner password is. If I try to run the manage-bde - tpm -o <password> command from a prompt, it reports an error "The TPM already has an owner." I think I am missing something obvious.... TIA

After you downloaded the base file (.exe), did you unblock it first? Right-click - Properties - Unblock.

If you are not seeing any drives from the debug prompt with the diskpart command, and after you partition your disks, I'd double-check your Format and Partition Disk step. Are you using the SCCM step or did you pass your own format parameters? Do you still have ramdrive and temporary partition drive (x: or d:)?

Is the PXE service running on SCCM 2012 server or are you running it on a separate WDS server? What version of PXE shows up on the client bios? What type of network switch are you running on? I've seen where the PXE BIOS code was incompatible with the (older) network switch code and wouldn't handle the PXE packet properly. I think the key is in your first message - that you are not getting the correct IP while in WinPE. If you aren't getting the correct IP while in WinPE, nothing past that point matters (as Peter33 aludes to). One way to check might be to set the Host table so that the MAC address of your system provides a static IP

Mine is set to before Setup Windows and ConfigMgr as well. I have the TS setup as a "Run Command Line" but I am calling mine in a .vbs script. cscript.exe //nologo "SetSiteCodeAuto.vbs" The one gotcha may be your XXX value, hopefully you are doing "tsenv2.exe set _smstssitecode=sXXX" 'XXX=sitecode (like "LM1") Note that you need the letter 's' in front of the XXX value. We are also running "tsenv2.exe set _smstssmp=sSERVER.FULLY.QUALIFIED.DOMAIN" value

My guess is that the img0.jpg has security rights that disallow you from renaming. Looking at C:\Windows\Web\Wallpaper\Windows\img0.jpg on my system it shows that Administrator only has Read & Execute, not Modify or Full Control. Have you considered replacing the background in WinPE after the Apply OS Image task but before the Setup Windows and ConfigMgr task or using GPO or a registry hack? Also see: http://www.myitforum.com/forums/Need-help-setting-default-background-using-SCCM-OSD-for-Windows-7-m232355.aspx

You could build a .hta front end called in the TS, use the form to select your location and then use the variable for the location to define your region/language/time etc.

Guessing it was a mandatory advertisement - but the advertisement has not expired? If it hasn't expired MS suggests you can re-run the adv. http://technet.microsoft.com/en-us/library/bb681010.aspx If it has expired you will probably need to create a new advertisement since those systems that checked in are done with processing that advertisement. Not 100% on that, but that's my guess on how mand. adv. work.

Are you partitioning the drive before you begin the installation? Do you have a diskpart or format step in your TS? Is this a previously BitLockered drive and it needs to be suspended or the TPM cleared first?

You can always use Boot Media, like USB or DVD, but your media will still need the proper network driver installed for it to communicate with the SCCM server to pull down the WIM. Or you can opt for a full media installation, but then you're not really using SCCM for your installation at that point.

The only times I've seen this is when the files have a hash mismatch. Resolving it usually comes down to deleting the package and redistributing. I don't know the cause, or if there is a better resolution. I've seen it rarely and the only correlation I could make was when there were a bunch of files going out to our DPs at the same time (The mismatch only appeared on one of multiple DPs). It is a pain to troubleshoot. Related article http://aditan.wordpress.com/2009/11/16/sccm-2007-clients-may-report-a-hash-mismatch-when-we-run-a-package-that-has-been-configured-to-download-and-run/

If the problem is on both new and old systems, I'd guess storage driver may also be an issue. Diskpart would be an important check point for reused systems. Are all the same computer models having an issue? Is so, check the Boot.WIM for the correct driver. Also check the dism.log for driver installation.

I'd look at the %windir%\logs\dism.log to see if you can tell which drivers are failing to load. You'll want to launch the debug window (F8) and hopefully you have trace32 in your toolkit/image to view it.

Here is a 2007 WQL statement you could try: select SMS_R_System.SystemOUName, SMS_R_System.Name from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Name like "%ISSUPPORT%" and SMS_R_System.SystemOUName = "DOMAIN/COMPUTER LABS"

No answers, but might provide clues: http://msdn.microsoft.com/en-us/library/cc784484(v=ws.10).aspx http://technet.microsoft.com/en-us/library/cc766489(WS.10).aspx

%ProgramData% you should be able to copy to. Your ConfigMgr package needs to run with administrative rights (run as SYSTEM) to access the ProgramData folder. If your package consists of License.lic and Install_License.cmd, your script could look like this: SET yourpath=%~dp0 XCOPY "%yourpath%License.lic" "%ProgramData%\Microsoft\Windows\blah\blahblah"

Which OS are you installing with - Win 7, 64-bit? If so, be aware that you cannot copy directly to the c:\ drive. Also be cautious of the syswow64 and system32 folders as well as the Wow6432Node registry key. For instance, a 32-bit command prompt will not be able to copy to the Win 7 system32 folder properly. <editorial>Why MS decided to keep the 'System32' folder for 64-bit, is so confusing....</editorial>