Joe

Sure. When dealing with configuration baselines and registry settings -- When you are creating an Execution Policy that looks at registry keys in HKLM\Software, make sure you tick the box for "This registry value is associated with a 64-bit application" if you don't want the rule to look in HKLM\Software\wow6432node. I was setting a windows setting, which wasn't really associated with a 32bit or 64bit "application". I passed by this setting without really thinking about it. I ended up creating a really weird text string that I could search for and found it under the wow6432node key. A lesson I won't forget!

Nevermind; it really was a stupid mistake that cost me half a day.

Sorry to bump an old post, but I wanted to share my solution to this same issue. While the solutions above didn't resolve my problem, it sure helped me find it! I recently had a handful of users report that a single software update was stuck deploying. It was hanging at the 0% downloaded phase. I couldn't really find any errors, but that may just be me looking in the wrong log. Anyway -- back in the sccm console, I did a quick search for software updates. I looked for everything that was deployed but not downloaded, and guess what I found -- this update was the only one that met my query. Apparently the download never happened but the update was deployed. When the clients tried to download the file, it didn't have anything to download!

Thanks for this note. I was having this problem and just implemented it. I'll know in 20 minutes if it worked! EDIT: Fixed my issue! Thanks again!!

He's asking you to put the drivers back into your build, and then run through another test deployment. When the machine fails, there is a file called smsts.log that will tell you why. It should be on the client you're building. I usually get this file for debugging by enabling debug support (F8) on the boot image. As soon as it starts to deploy, I press the F8. This opens a command prompt. Move this out of the way so you can see the failure. The command prompt will stop the machine from rebooting. Once you get the failure, then copy the file off the machine to a place where you can attach it to this thread. No; removing the driver package does not remove the driver from Configuration Manager. When dealing with drivers, you have them in two locations. First, you have to import the driver into Configuration Manager. Think of this as getting it into the Configuration Manager application. This is exposed under the Drivers node. Once you've imported the drivers, you have to create a driver package. This is content, meaning it allows your clients to actually use the driver. This is exposed under the Driver Packages node. If you want to remove the driver completely from the Configuration Manager, you'll have to remove the driver and then update all of your distribution points with all the packages that contained that driver.

Greetings: I recently upgraded to R2. I had a problem with the database halfway through the install. According to the install, it completed successfully, but I've noticed that I'm not seeing some entries that used to be in pkgxfermgr.log. Prior to my R2 upgrade, I could actually see logs that would tell me what servers were receiving what packages. Now I only see logs like this: Sending thread starting for Job: 10752, package: CCM00089, Version: 1, Priority: 2, server: MYDP.Contoso.com DPPriority: 200 SMS_PACKAGE_TRANSFER_MANAGER 12/11/2013 7:34:33 PM 6340 (0x18C4) Yield 19 seconds due to bandwidth control, the current sending rate is 10 percent, the estimated bandwidth is 480597 bytes per second SMS_PACKAGE_TRANSFER_MANAGER 12/11/2013 7:34:35 PM 6300 (0x189C) Yield 19 seconds due to bandwidth control, the current sending rate is 10 percent, the estimated bandwidth is 480597 bytes per second SMS_PACKAGE_TRANSFER_MANAGER 12/11/2013 7:34:35 PM 5508 (0x1584) Yield 45 seconds due to bandwidth control, the current sending rate is 10 percent, the estimated bandwidth is 200248 bytes per second SMS_PACKAGE_TRANSFER_MANAGER 12/11/2013 7:34:35 PM 6148 (0x1804) Yield 45 seconds due to bandwidth control, the current sending rate is 10 percent, the estimated bandwidth is 209715 bytes per second SMS_PACKAGE_TRANSFER_MANAGER 12/11/2013 7:34:36 PM 5780 (0x1694) Yield 18 seconds due to bandwidth control, the current sending rate is 10 percent, the estimated bandwidth is 524288 bytes per second SMS_PACKAGE_TRANSFER_MANAGER 12/11/2013 7:34:38 PM 6588 (0x19BC) Prior to the upgrade, I could actually a line between these that would tell me it was sending x bytes to the server. Because of my upgrade problems, I'm wondering if something is broken. Can someone check their logs and let me know if you see this missing line, or if it's just me? I appreciate your help! Thanks!

It's failing to install Office 2010. It looks like the task starts to install Office 2010 Standard at 5:12, and then fails around 5:28. If you're deploying apps using a variable, make sure the app is configured to allow it to be installed without being advertised. Without that enabled, it will fail. 14 minutes is also interesting -- have you configured the install to run for only 14/15 minutes? If so, are you certain this is enough time to finish in your environment? Make sure the setup is 100% automated -- if it's not, it will never finish and you'll end up with this error. I interpit the logs as saying this: 5:12 - Install Office 5:18 - Are you done? (no response) 5:23 - Are you done? (no response) 5:28 - Are you done? (no response) 5:28 - This step failed, and the Task sequence says to not continue if this task fails, so abort

Good Morning: I have a simple SCCM 2012 Hierarchy; a single Primary Site and many distribution points in the field. The Primary Site server is running out of disk space because of Software Updates. I need to replace it with a machine that has more disk space, as it is not currently possible for me to upgrade the disk on the Primary Site at this time. Does anyone have any recommendations on doing this, or possibly some links to documentation? I am considering a P2V of the primary site server, which should get the job done. But I want to make sure it's the correct path. Any insight is helpful and much appreciated. Thanks,

Wow; I really didn't read what you said. I'm sorry about that!

You don't need to raise the domain or forest level to manage the devices. You only need to do this if you want to take advantage of the changes that Server 2012 introduced to Active Directory. Group Policies are technically not part of Active Directory, so they don't require the domain/forest levels to be at a specific version to work. You're definitely going to need to stand up a 2012 server. You can make it a DC if you'd like, but you don't have to. It just needs to be a member server in your domain. On a side note, DCPromo is still there and is only used for silent installs of Active Directory. For manual installs, you use Server Manager. But like I said, you won't need to do this. Once you have your 2012 machine up and running, just create a policy for it your Win8 machines and apply it only to those machines. Make sure you manage the Win8 policy with the 2012 machine and then continue to manage the older operating systems the way you did in the past.

Greetings: I'm running into some problems with my maintenance windows, and I'm hoping someone can point out what I'm overlooking. I've been trying to find a way to manage maintenance windows in my environment. Initially I was assigning maintenance windows to the collections that provided the software updates (ie, a collection for Windows Updates with a maintenance window, a collection for Office updates with a maintenance window, etc). I've decided that this is rather confusing and is going to be difficult to tell when a machine has a maintenance window. To resolve this, I created specific collections that do nothing other than provide a maintenance window. This seems the easiest way to manage in my environment. Now, each maintenance window has it's own collection and I can add machines and easily see what the maintenance windows are with a few powershell commands. At present, I only have one maintenance window defined. I have gone through and removed them from all collections except one. However, using both PolicySpy and Client Tools I see multiple maintenance windows. I have updated the machine policy, but I still only see these multiple maintenance windows. Is there somewhere that I'm forgetting to look where a maintenance window can be configured? EDIT: Maybe I'm reading too much into this. I reviewed the built in report "Maintenance windows available to a specified client" and all looks well.

I am using SP1. Since it's a known issue and Microsoft is working on a fix, I guess I can just manually install on these machines to get the client going. It's odd, though -- shouldn't the expiration prevent (or at least generate a warning) the installation of the MSI manually?

Greetings: I'm rolling out a new SCCM 2012 environment. I have 81 clients that I'm trying to bring into my environment from an existing 2007 environment. I configured discovery so they were identified by configuration manager, and then pushed the client to all of them. About 20% of the machines are failing to install the client, and they're all getting the same error: c:\windows\ccmsetup\logs\ccmsetup.log: Couldn't verify 'C:\Windows\ccmsetup\MicrosoftPolicyPlatformSetup.msi' authenticode signature. Return code 0x800b0101 It appears that the installation isn't liking the MicorsoftPolicyPlatformSetup.msi authenticode signature, and I'm not quite sure what to do about it. Since the majority of my clients installed without problems, I'm pretty sure the problem isn't with the source files. To make sure something wasn't getting corrupt data copied over, I did a file compare (fc <file1> <file2>) from a command prompt. The files are identical. I thought maybe an error message might be getting hidden during the install, so I decided to run the microsoftPolicyPlatformSetup.msi manually and see what happened. No errors were generated. However, after installing this manually, I was able to push the client successfully from the console. Any ideas?

I use a front end to allow the person building the machine to totally customize the build. Each option is represented by a variable that gets attached to the computer object in sccm. If you look at the second tab on all task sequence steps, you'll see a spot where you can tell the step to only happen if a task sequence variable is set to a specific variable. When you run the sequence, if there is a variable on the computer object, it "becomes" a task sequence variable and you can use it to control what happens. I use about 40 different variables to control my Windows 2008 builds. Works like a champ. The hardest part is getting the variable attached to the computer object, but once you get past that, its cake. To manually add or view variables, look at the computer object in sccm in the collection node.

Have you tried disabling 64bit redirection on the task? I'm not sure if that is causing your problem, but I always tick that box when I'm trying to make a systemwide change... just to make sure something isn't redirected since ccm is a 32bit process.

Are you using a settings package? Does it contain settings for the proper OS that you're trying to deploy? You can always try disabling the settings package and then deploying. If it works, you know it's something in that package (probably with unattend.xml). You might get some more information if you did into the C:\Windows\Panther folder. One of the logs in that directory might be more useful than your CCM logs at this point.

ccmclean removes ccm components from the workstation -- I didn't think it removed the machine from the SCCM database, too. I could be wrong as I have never tested to verify.

Just change your boot image over to a 32bit image. You don't need a 64bit WinPE unless you're doing a build/capture sequence. For future reference, you can deploy x64 and x86 using a single task sequence. I currently do this and it works great. The plus side is that I only ever have to modify one task sequence and it impacts both platforms. Much easier than maintaining multiple task sequences.

Can you elaborate on this? Deployment is all based on Advertisements. If you build 6,500 machines, and 1 of them fails, it isn't going to impact the other 6,499. You will be able to examine the failed build and troubleshoot it. If it fails, you should be able to PXE boot again and restart the build immediately.

Once you import the driver, assign it to a driver package, and then replicate the package to your distribution points, you need to tell the task sequence to use this driver. You can do it two ways: 1. Auto Apply Drivers This will apply all drivers based on the Device ID. 2. Apply Driver Package This will only apply the drivers in the specified driver package. I always use option 2 with my builds. I specify a WMI query that matches the hardware it's intended for. I group my driver packs based on machine type and apply them only to the hardware I intend to. I've had problems with Auto-Apply drivers, so I don't use it. Both of these tasks are available in the config manager Task Sequence editor. Just right click on your task and choose edit. Once in the editor, click Add (upper left) and then Drivers. You'll then see the two options. Hope that helps!

Thats ok -- it's got a default value that is used when it's not defined. I believe it's 3600 (an hour). However, if my understanding of this value is correct, it should only be impacting you if you are rebuilding the same machine over and over. Given that you said you wait a long time and it still fails, I don't think this is your issue. Take a look at KB976073. I'm fighting with the same issue in my environment. Everything looks good -- no errors in the logs -- but sometimes I just have to restart WDS because it seems to stop responding as described in this article. The hotfix seems to have helped (I only get calls once a week instead of twice a day), but it still happens.

I figured it out! This post can be deleted.

Is anything appearing in the list, or is it just missing the driver for your storage controller? If nothing is appearing, then your mass storage controller driver doesn't have a TXTSETUP.OEM file. This file is required to tell the task that it's a text mode driver. Without it, a the drop down list will always be empty. If you don't recognize the driver, then you'll have to get the device ID and match it to something in the INF file. You can also use this method to see if your driver even supports that controller. I've attached a text file. If you rename it to VBS and run it, it will spit out a text file with some information about the storage controller (and some other stuff). I use this when I'm prepping a new model for XP deployments. If you're having problems, the output of this script might help you identify the driver that you need. Just make sure it has that TXTSETUP.OEM is in whatever driver you grab.

Every time I get a 7B it's becuase I either didn't specify a mass storage controller, or I gave it the wrong one. If you downloaded the driver direct from HP, it doesn't mean that you have the correct one. Textmode setup drivers usually contain drivers for more than one controller, so not only do you have to find the right package, you have to specify the correct dirver. This is how I do it: 1. Download the driver from the vendor. Copy it to a network location -- what I call the driver repository. They are stored in a directory like this: \\Server\Share\SCCM\Drivers\<Make>\<model>\<os>_<arch>\<hardware> or \\Server\Share\SCCM\Drivers\HP\DC7800\WinXP_x86\Mass_Storage 2. I then run a script on the machine. It generates a text file and tells me a little bit about the hardware. It also generates a WMI query from the BIOS that helps me identify the machine later. I'll attach the script below. 3. I rename the text file that the script generates to <os>_<arch>_<make>_<model>. In this case, WinXP_x86_HP_DC7800 4. I copy the text file into each of the drivers that I've copied to in step 1 -- usually it's just the Mass Storage Driver, but sometimes it's a NIC too. Putting this file into the directory makes it unique to SMS so I can have multiple copies of it for different pieces of hardware. This is important since I don't use the Auto Apply Drivers. 5. I have folders in my Driver Packages that break the driver packs up by OS and Architecture. Something like this: WinXP_x86 Win7_x86 Win7_x64 I will create a new driver package in the apropraite folder. The name is based on the machine type and model. In this case, I would create: WinXP_x86\HP_DC7800 4. I have duplicated the folders from my Driver Packages into the Drivers Folder. This helps me keep drivers organized. I then import the drivers into the apropriate folder and assign them to the correct driver package. I never assign them to boot media becuase, if the import fails, it can cause problems with your boot media. I do that manually if necessary (and with XP, it's usually not necessary). 5. Make sure you assign and update a distribution point for your driver package -- if you don't, it will fail to deploy the driver later!! 6. Now I edit my task sequence. I add a Drivers > Apply Driver Package task named (in this case) HP_DC7800. I put a check in [x] Select the mass storage driver within the package that needs to be installed before setup on Pre-Vista operating systems and choose the Driver. Under the driver drop down, I usually see two drivers. One of them is a RAID controller, and I don't usually select this one. I then refer to the text file that the script generated in step 2. This helps me pick the right model. 7. I now click the options tab of the task I just added. I add a new condition and choose Query WMI. I then paste the query from the text file generated in step 2. This makes sure it will only apply to this model of machine. I now PXE boot and deploy the OS to the machine. After the WIM is deployed, the drivers will be injected by the Apply Driver Package task. It will then inject the correct driver and (hopefully) prevent the Stop 7B error from occurring. Hope this helps! ' OSD New Machine Prep ' This script will collect certain information that is required ' and/or helpful to quickly add a machine to OSD. ' ================================================================================ Option Explicit Dim report : report = "" Dim wmiModelQuery : wmiModelQuery = "" Dim model : model = "" Dim manufacturer : manufacturer = "" Dim reportName : reportName = "" Dim storageReport : storageReport = "" Dim NICReport wmiModelQuery = getWMIQuery reportName = manufacturer & "_" & model & ".txt" storageReport = GetStorageReport NICReport = GetNICReport buildReport saveReport Sub SaveReport() Dim oFSO Dim Result Dim oFile Set oFSO = CreateObject("Scripting.FileSystemObject") If oFSO.FileExists(reportName) then Result = msgbox ("Report already exists: " & reportName & vbcrlf & vbcrlf & "Would you like to overwrite it?", vbYesNo + vbQuestion, "Save Report") If result = vbNo then reportName = inputbox("Please enter a new name for the report:", "Save Report:", reportName) SaveReport wscript.quit End If oFSO.DeleteFile(reportName) End If oFSO.CreateTextFile(reportName) Set oFile = oFSO.OpenTextFile(reportName, 2) oFile.Write Report oFile.close msgbox "Report was saved as" & vbCrlF & reportName, vbOkOnly + vbInformation, "Save Report:" wscript.quit End Sub Sub buildReport() report = report & "OSD Deployment Information" & vbCrLf report = report & "[" & reportName & "]" & vbcrlf report = report & "Date: " & date & vbcrlf report = report & "===============================================================================" & vbcrlf report = report & "|WMI Query|--------------------------------------------------------------------" & vbCrlf report = report & "This query is used to uniquely identify this machine type. Drivers will be " & vbcrlf report = report & "assigned based on the results of this query. " & vbcrlf report = report & "-------------------------------------------------------------------------------" & vbcrlf report = report & "" & vbcrlf report = report & "===============================================================================" & vbcrlf report = report & wmiModelQuery & vbcrlf report = report & "===============================================================================" & vbcrlf report = report & vbcrlf report = report & "|Storage Controllers|----------------------------------------------------------" & vbcrlf report = report & "The following table shows a list of storage controllers in this workstation. " & vbcrlf report = report & "It can be used to help identify a storage controller for legacy OS Deployment. " & vbcrlf report = report & "-------------------------------------------------------------------------------" & vbcrlf report = report & vbcrlf report = report & storageReport report = report & vbcrlf report = report & "|NIC Configuration|------------------------------------------------------------" & vbCrLF report = report & "The following is a list of all network controllers in this machine. " & vbCrLF report = report & "-------------------------------------------------------------------------------" & vbcrlf report = report & NICReport report = report & vbcrlf End Sub Function GetWMIQuery() Dim objWMIService Dim colSettings Dim objComputer Dim Query Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") Set colSettings = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem") For Each objComputer in colSettings query = "Select * From Win32_ComputerSystem Where Manufacturer=" & chr(34) & _ objComputer.Manufacturer & chr(34) & " AND Model=" & chr(34) & _ objComputer.Model & chr(34) manufacturer = objComputer.Manufacturer model = objComputer.Model getWMIQuery = query Next End Function Function GetStorageReport() Dim strComputer : strComputer = "." Dim objWMIService Dim colItems Dim objItem Dim buffer : buffer = "" Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_IDEController",,48) For Each objItem in colItems Buffer = buffer & "Caption : " & objItem.Caption & vbcrlf Buffer = buffer & " Device ID : " & objItem.DeviceID & vbcrlf Buffer = buffer & vbcrlf Next GetStorageReport = buffer End Function Function getNICReport() Dim objWMIService Dim colItems Dim objItem Dim Buffer : buffer = "" Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_NetworkAdapter",,48) For Each objItem in colItems Buffer = buffer & "Caption : " & objItem.Caption & vbCrLf Buffer = buffer & " Manufacturer : " & objItem.Manufacturer & vbCrLF Buffer = Buffer & " Device ID : " & objItem.PNPDeviceID & vbCrLF Buffer = buffer & vbCrLf Next getNICReport = Buffer End Function

Well, just like every other problem -- spend hours looking at it, can't figure it out. Post a question and you find the answer not 2 minutes after you hit the post button. If it helps anyone else -- my problem was that there was in fact an error in the log files and I missed it. I had an install software updates task that I must have accidentally dragged into the wrong spot. I moved it back and I'm back in business. Sorry to be a bother!