Mikey C

actually, while i am here - Will machines get policies if their time is inaccurate but date correct? Is being out by x number of hours OK, and if so, what does x equal? AD/GP is 4 hours by default isnt it? Or is it 1? Thank you

Cheers Niall, it is working fine now, strange. Thanks for responding. FYI It was this one: Step 1. Download the following script WinPE_timesync.zip 1.49KB 185 downloads

Hi Niall There is a 404 on that script download, can you check it please?

So basically WSUS and SCCM are not talking to each other, i would definitely do the same as posted above, carrying out each of the following steps carefully accurately (attention to detail again!!!) ) 1. Uninstall the SUP role. Wait until you are certain this has completed, or check the log to make sure. 2. Reboot SCCM server. 3. Uninstall WSUS, verify this has completed successfully, even log should help. 4. Reboot WSUS server. 5. Install WSUS. 6. Install first update. 7 Reboot 8. Install second update depending on OS i think.... 9 Reboot 11 DO NOT GO INTO WSUS CONSOLE AT ALL EVER! 12 Add SUP role to SCCM 13 Wait until that completes, check the SCCM server logs to confirm 14 Configure/confirm SCCM SUP settings are as required (i would recommend only ticking a couple of products for testing 14 Trigger a WSUS sync from the SCCM console. 15 Check the status of SCCM logs. Post back to let us know how you got on.

Mikey, not Mickey Attention to detail!!!.....

It says quite clearly in the above log file REFER TO THE WCM.LOG FOR CONFIGURATION ERROR DETAILS. Have you done that? Have you attached the WCM.log to the forum?........

Post the script on here

I agree, your client does not seem to be pointing to a WSUS server. It is checking MS for updates via internet. What is in the above registry key?

I do not understand what your requirements are, you say you are trying to name PCs based on site, therefore automate the PC naming, but you continue to say you want the script to prompt for a computer name...

from wsyncmgr: Failed to sync update 91efe48b-7f85-4a74-9f33-26952da55c80. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted. Source: Microsoft.UpdateServices.Internal.BaseApi.LicenseAgreement.GetById SMS_WSUS_SYNC_MANAGER 05/06/2014 11:57:43 3148 (0x0C4C) Failed to sync update 20c93660-7d50-4ffb-a621-688ccc973abf. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted. Source: Microsoft.UpdateServices.Internal.BaseApi.LicenseAgreement.GetById SMS_WSUS_SYNC_MANAGER 05/06/2014 11:57:45 3148 (0x0C4C) Identify what these updates are: 91efe48b-7f85-4a74-9f33-26952da55c80 and 20c93660-7d50-4ffb-a621-688ccc973abf I have seen this issue "The Microsoft Software License Terms have not been completely downloaded and cannot be accepted" before, but i cannot remember what the solution was. You could try removing these two updates from the package, as a workaround

Have you searched all local disks of your sccm box for the PatchDownloader.log? Do you have wsus and sccm on the same box?

The process I follow which works pretty well is: Add Vanilla WIM. Offline service updates into the WIM (either using SCCM console or using dism) Use that WIM in a build and capture TS which has update steps which installs all non Windows updates and any recent updates (as well as installing all c++/.NET pre-reqs etc. Then use that captured WIM in the deployment TS which has no update step, making it much faster. The Deployment TS writes the build version to the OS description and that version no. is updated when the B&C is updated. This would eliminate any mismatch between the updates your machines have, so you are maintaining a baseline per build, indicated by the version number. This also makes supporting issues with your desktops that may be update related more straight forward as you can compare builds. Hope this helps!

InstallTargetUpdates failed, error 80040708 It seemed it isn't seeing the updates. Make sure you have advertised updates to the collection. Also, deploying the updates to the unknown computers is an option. There are definitely some updates installing to the machine the logs have been taken from.....So perhaps not the updates you want are deployed to the collection the device is a member of?

When you have a large number of updates deployed to a device, each one has a policy, and each policies is deleted from the device as part of the above process. It will take a long time, but this is normal and required.

So you are saying that you want to automate the process of naming a PC to reflect "our sites"? Good, this is a much better idea than relying on technicians to not get a typo. Human beings make mistakes, they cannot be relied upon. You could set task sequence variables based on the information that is unique to each site. For example a subnet is detected when a device is image on site. Then you vbs can use that information to generate and populate the OSDComputerName - Is this the kind of thing you are trying to achieve?

Please ATTACH these three log files TO THE FORUM, or POST THEM ON Dropbox: wsyncmgr.log PatchDownloader.log WCM.log

Did you read my post?

This worked for me

I have experienced this. Basically, the device which is running EFI mode PXE will not boot from that 32-bit boot media. You cannot specify directly, which boot media a device will use (whether 32 or 64 bit), but when you deploy a task sequence, the boot image associated with it becomes the chosen one' that client machines will PXE boot from. So re-deploying a 64-bit task sequence might solve the problem for you, but we have some devices (Lenovo Tablet 2 devices, they are crap) which will only boot in EFI mode and only from 32-bit media, they cannot revert to BIOS mode, and they cannot run 64-bit code. So, this means that we cannot PXE boot 64-bit devices, we can only boot them using USB flash drives. If anyone has a better workaround, or knows why the 32-bit boot media causes the "Windows Failed to Start" message above on 64-bit devices, please let us know!!

mkan You would be better attaching the log files themselves, rather than pasting the contents, it means we can open them in log viewers which makes reading them much easier. If they are too large for the forum, post to dropbox/gdrive/onedrive etc.

I think this is a known problem which MS have not yet fixed/identified but other users are also experiencing the same http://social.technet.microsoft.com/Forums/en-US/54458340-e50d-4144-af0d-33c768861e97/osd-ts-fails-during-package-download-sendwinhttprequest-failed-80072ee2?forum=configmanagerosd I will add the solution from Technet for completeness on here: QUOTE: We got a reply from Microsoft - The issue as been verified in their lab, and they are working on a proper solution. - The workaround suggested by them is as follows: Create two Task Sequence Variables at the very top of the TS, right below "Execute Task Sequence" SMSTSDownloadRetryCount = 5 SMSTSDownloadRetryDelay = 15 I've done this myself, and the TS now completes. Just wanted to confirm that this worked for me at a recent client, another MVP also had the issue and it worked for him as well. Setting the variables, also improved the OS image download speed as well. Microsoft is aware of the bug and it's filed, hopefully we'll have a hotfix to address soon. Chris Nackers Microsoft MVP - Enterprise Client Management

This is an intermittent issue which is happening on the occasional device. We are not imaging many machines, about a dozen devices a day at the moment. The vast majority work, there is only the occasional failure due to this reason. In other words, the account is not locked, not expired and not disabled and works nearly all of the time.

This is a task sequence which is run fairly regularly without issues. The package OB100168 is used in every deployment and has no issues normally. Therefore I am starting to believe there is a network issue somewhere. Can anyone see from the attached if that is the cause? smsts.log

To double check NIC driver is the cause, press F8 and run ipconfig.

Not sure if i have the same problem as in this thread..... When we PXE boot devices with disk encryption (bitlocker, mcafee or checkpoint), we obviously cannot run any command in WinPE to be able to access the disk to download the boot WIM, which is necessary due to the really awful SCCM issue whereby the boot media associated with the LAST task sequence that was deployed, is the one that is run when PXE booting, even if it does not patch the media associated with the TS that is deployed to that specific device. The end result is that the device must pull down the correct boot media, which it cannot do as all partitions are encrypted. Has anyone else experienced that and have a decent workaround for it? it is especially problematic for EFI devices that will only run x64 media, and therefore will not even boot from x86 media.