Jump to content


Steve G.

Established Members
  • Posts

    27
  • Joined

  • Last visited

Everything posted by Steve G.

  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.
  16. Thanks for the reply. I did indeed use this guide, both long ago when setting up SCCM 2012, and recently trying to figure out the conundrum. I defined the policy setting just so, and the result was the Group Policy Conflict error. Question: Do you deploy Endpoint Protection via SCCM, or do you use another antimalware client? It was definition update deployments that started generating the errors.
  17. I've run into a problem with software update-based installation. I'm curious to know if others have experienced the same issue. This method of installation puts the client on the WSUS server that holds the software update point role. The intent is that clients will download and install the client that if they have that SUP role server defined as their default WSUS server. However, in my environment (and many others, I suspect), this must be effected through the use of a group policy which A) defines the WSUS server, and configures the update installation schedule. Just pointing computers to the WSUS server accomplishes nothing if the computers are not also told to automatically download and install updates on a schedule. However, once that download/install schedule is defined, update deployments start to go awry. "Group Policy Conflict" shows up as the error message. Searching for solutions shows many folks saying that group policy should not be used to define any WSUS settings for computers with a 2012 client. So, this seems to be a catch-22, but not one that I see any real discussion of. I need to configure WSUS policy to get the client on the computers through this method, but then once the computers have the client the policy will cause deployments to fail. I might at this point try a WMI filter on the policy, but was wondering if I was missing something simple here, since nobody else is complaining (as far as I can tell).
  18. How are the updates being deployed? Are you creating a software update group every month, or aggregating them? Do you create multiple deployments, or do you target all systems with a single deployment? Screenshots might help.
  19. This is something I see a lot of with Patch Tuesday deployments. My takeaway is that "Unknown" is something of a misnomer. For each system, a deployment's status starts as "Unknown", moves to "In-Progress", and finishes as "Compliant". What's missing from the UI that ought to have been included is a "Pending" or "Waiting" status. This is vexing because in 2007, you could easily open a log that aggregated all client messages in one place, and would display the advertisement status at every step. You would get a notification as to why it hadn't started yet. In 2012, on the other hand, a computer that has not yet kicked off the deployment remains in the hellish limbo of being "Unknown", with no details provided at this step. If you want to know why, I'm afraid you must strap on your pit helmet and start digging through client logs one at a time. If active clients are remaining in an unknown status for a long time for a required deployment, that may indicate that they are processing some other deployment, with a likely hold-up being a pending restart (at least on mine, as we don't force workstations to reboot after updates).
  20. Last week (7-10 days ago from this posting) I used the client push wizard to deploy the client to about 700 computers. I noticed earlier this week that they had all failed their client checks, so I ran a batch repair on them. They are now active, and have an appropriate site code, and are approved, but despite all of this as far as processing software deployments goes, they all remain "unknown". "Unknown" indicates the client has not processed the machine policy. So, unless I'm misunderstanding the situation, the client is either seriously defective on hundreds of computers, or it's not returning the results to the server for some reason. The SMS services are running, and I rebooted the server last Sunday. The components also show no aberrant behavior. Any ideas on where else to go with troubleshooting would be welcome. It's a single-site setup, with the only remote component being the SQL database. I need to start weeding through logs more heavily, but I'm not sure which would be most likely to reveal the root problem.
  21. Indeed, lack of information is the very issue. I thought for a time that it was related to boundaries and distributions points, but I can see the computers that require the update, and they are not of one specific type or located in one specific location. My guess would be some kind of client issue. Hopefully, it's not WMI-related.
  22. Since about the beginning of the year, I've started see a large number of clients that never tick over from "Required". Can anyone recommend a good practice that might help indicate why updates won't install for a given computer? Perhaps a canned report that indicates the issue?
  23. The overall compliance report works off of an update list. So essentially, I'd have to build a massive update list with every update. I suspect that if I made it something broad like all Windows 7 updates, I'd wind up hitting the same kind of cap I run into with software update groups in SCCM 2012. Worse still, if it is similar to the Overall Compliance report in 2012, then it's just as impractical. What that particular report does is show compliance as a binary state. Computers are either compliant (because they have every update in the specified SUG) or non-compliant (because they are missing even just one). The user can then drill into the report by clicking on individual computers to see all the updates in the universe that are applicable to it (even those not deployed to the SUG), with asterisks in the "Approved", "Installed", and "Required" columns. This does not seem to be an effective means for an admin to provide management with a snapshot view of update compliance.
  24. I've been tasked to generate some reports that will show update compliance. The thing that is not easy for the requestor to appreciate readily is that our enterprise has thousands of computers and there are thousands of updates in question. So, how can such information be presented in a spreadsheet in a practical, digestible fashion? I could try to generate a report that shows all the computers and then puts their compliance stats next to them (updates #, required #). Or I could try to generate an even more elephantine report with all deployed updates and their compliance stats (computers installed #, computers required #, unknown #, compliance %). Doesn't look like there's a canned report that does either of these for me. The absence of a canned report gives me the suspicion that I'm missing out on a proper way to skin the cat. Our SCCM environment haven't utilized either update lists or configuration baselines, so would these be of help? Thanks! EDIT: Just to clarify, I am talking about overall compliance for updates, not a single specific update or deployment.
  25. We're going through the process of standardizing servers to 2012, and unfortunately I built Config Manager 2012 on WIndows Server 2008. Now, I know that there's no officially supported upgrade path, and it's likely not feasible from a practical standpoint anyway, so it looks I'm rebuilding everything all over again. Such is life. Is a database backup and recovery the easiest way to go about this? Is there any advantage to trying to build the 2012 server side-by-side, make it another site, and then migrate all the roles over? The latter sounds like more trouble than it's worth, but maybe someone who's actually been through this before might have some insights to pass along. Thanks.
×
×
  • 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.