Jump to content


Steve G.

Established Members
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Steve G.

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Atlanta
  1. You're talking about "seeing" computers. You're talking about when they become members of a collection you're looking at? If so, the administrator may be looking at a collection that updates more quickly than the one you're looking at (or the administrator is not making it clear that he's initiating an update of the membership on his collection). Look at the properties of the collection you're looking at under the Membership Rules tab. Are the boxes checked for incremental updates and/or full updates? Is there a schedule?
  2. Look in your client's WUAHandler log for a periodic event where it tries to point the client to an update server. Is it the server holding the Software Update Point role assigned in Config Manager? Look in your client's registry to see what is listed at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate. Is it your SUP role holder? Run RSOP on your client and look to see if any policy is applying at Computer Configuration/Administrative Templates/Windows Components/Windows Update .
  3. Without details on the cause of the installation failure, any thoughts shared would be vague in the extreme. Look at the ccmsetup.log on clients for errors. Look at your All Systems collection and see what number is identified on the "Last Installation Error" column. Are you actually seeing the client fail to install on specific machines that you have access to, or are you just looking at the collections in your console and seeing a bunch of computers without clients? If Config Manager is discovering clients in Active Directory, then it will include any accounts that haven't been disabled or deleted. It has no way to know what's stale. The Last Installation Error for non-existent systems is usually 53.
  4. Yeah, we had lots of issues jumping straight from 2012 R2 to 1610. So, you use client push installation or software-update-based installation? Do you use GPO's to configure the WSUS source? Or is that configured in local policy, perhaps on your image? Verify that the update server is registered correctly clients' WUAHandler log (don't just look for red highlights in CMTrace as we SCCM admins are wont to do). If the server name is correct, make sure the port matches whatever your HTTP (or HTTPS, if applicable) port is for Update Services in IIS.
  5. I don't have MDT, MBAM, or the Maik Kosters web service. I can go install all the stuff, but can you help me appreciate how MDT will address what seems to be a USMT limitation? The TS is pretty simple. It doesn't boot to any kind of PE. One task creates a TS variable OSDStateStorePath, and has a value that points to the mapped drive. The Capture User State task that follows it is perfectly vanilla.
  6. I attempted to import the task sequence, however even with ignoring the dependency, the import failed with an error: Error: Imported Task Sequence Package (1): Ignore Dependency CM12 UEFI BitLocker HTA Not found instance of __ExtendedStatus{ Description = "Failed to load class properties and qualifiers for class BDD_UsePackage in task sequence."; Operation = "ExecMethod"; ParameterInfo = "SMS_TaskSequence"; ProviderName = "WinMgmt"; StatusCode = 2147749890;
  7. Thanks for the response. It's interesting that there's no error capturing a user state directly to network storage, since both USMT 4 and 5 have not been able to do so in our environment. When we opened a ticket with MS, they said this was intended behavior.
  8. Here's what the scenario: Potentially hundreds of computers to replace. A couple dozen PC technicians. One (1) SCCM administrator. Management insists that data be backed up prior to OS deployment in the event of catastrophic failure during occurring during said deployment. In Config Manager 2007, this was simple enough to handle. We had a handy-dandy task sequence that mapped a drive to a network share, and then ran the backup to that location, with a little variable that named the file after the source computer. If anyone ever needed data restored, they could just fire up Windows Easy Transfer and look for that file. Sure, we did hard-linking and in-place backups and restores, but it was definitely helpful to simply have the data sitting on mass storage and accessible to people who weren't SCCM admins. In Config Manager 2012, however, a USMT task sequence fails with an error that indicates it doesn't allow backups to mapped drives. Now, everything I've read about state migration points seems to rely creating manual one-to-one relationships between the source and destination computers, which doesn't seem practical with large scale deployments. It also seems to necessitate using SCCM to perform all restores, so a PC technician can't just snag the backup and restore it. Has anyone had to face such a scenario? Are there any good guides for USMT to facilitate an en-masse PC-replacement?
  9. Jorgen, thanks for the reply. Yes, I used a GPO in 2007. I swapped out that GPO with a new one. It's definitely working in terms of setting the WSUS server location in computers' registry. It's just not pushing the client. I should add that I incorrectly provided http:\\SUPserver.domain:80 as the location for the server. It's actually http:\\SUPserver.domain:8530, as the server in question is running Server 2012.
  10. Getting workstations to automatically install the client agent via SUP shouldn't be a complicated matter. It should simply entail 1) enabling this method of installation from the administrative console and 2) configuring a group policy object that directs computers to use the SUP as their WSUS source. After that, computers should receive the client agent as a critical update. Or so I thought. Worked fine in 2007, but my 2012 computers aren't getting the client. It seems like the GPO is the only real point of failure here, but there's not much to it. The GPO currently has two configurations. One specifies http:\\SUPserver.domain:80 as the WSUS server, and the other configures computers to download and install updates once a day. I've looked at the Windows-Noob guide, and it doesn't look like I'm missing anything.
  11. If you wish to vet your updates for your servers, you simply don't use ADR's. ADR's were created primarily as a way to push out FEP definition updates on a daily basis, as an alternative to going into WSUS and auto-approving them. Thus, they lack some common-sense functionality like excluding updates that are too recent. Instead, create a custom software update search that excludes the last two months, and deploy that. Save that custom search and you can use it every month to add new patches to the SUG, or create a new SUG to deploy every month (whether to use the former or latter mostly has to do with how you handle server reboots).
  12. Because of IE pushes, it is IMO unwise to automatically deploy the Update Rollup classification. However, there are extra steps I also take. I go into the WSUS console on the Software Update Point and decline the update. On the SCCM console under Software Updates, I created a folder to move all IE updates to. This helps prevent any kind of accidental deployment.
  13. FWIW, I"m going to go ahead and configure an update schedule to automatically download and install. If I get errors again, I'll post'em.
  14. I think you'll find that pretty much nobody deploys updates one by one. They are typically either grouped into software update groups by month, or lumped into a larger "overall compliance" software update group.
  15. The definition update ADR runs every day, so that's the one that started showing errors first. Here's a thread in a similar vein in which you participated: http://www.windows-noob.com/forums/index.php?/topic/6142-scepsup-and-gpos/ Personally, I don't have a problem with specifying a WSUS server location via policy. The errors start once an update install schedule has been configured.
×
×
  • Create New...