Jump to content


Mikey C

Established Members
  • Posts

    97
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Mikey C

  1. 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!!!) :P )

     

    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.

  2. Hi,

     

    I have problem in configuring the WSUS in SCCM 2012 R2. I tried all the options which you have mentioned, but did not work. Could you please help me out in configuring the same. I have attached my log file for your reference.

     

    We are using proxy server to connect the microsoft site with authentication.

     

    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?........

  3. i all have a script which prompts for computer name for all unknown computers. But i would like the same to work for Known computers instead of it reusing the information already recorded in SCCM (forget the sites thing this will be done manually by the engineer rebuilding the device when prompted for computername)

     

    apologies if i didn't explain it very well.

     

    Post the script on here

  4. 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

    • Like 1
  5. 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!

  6. hi again.. here comes the link to some logs, including windowsupdate.log

    https://onedrive.live.com/redir?resid=B69CD1CE01868052%2123727

     

    please help me with this, it is annoying that i get zero patches during OSD with win8.1 when our win7 OSD works, same ADR to both Collections.

     

    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?
  7.  

    seems like the task failed during the wmic, feels like something goes wrong with the cm install, initializing takes forever and no updates get installed. will check the logs tomorrow at work

     

    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.

  8. our computer names reflect our sites and the engineers move them around..............they don't want to have to manually rename after build.

     

     

    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?

  9. 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!!

  10. 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

    blog.jpg glossy-cute-blue1.png linkedin-icon.png

  11. 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.

  12. 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.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.