dverbern

We have configured a "Refresh" OSD deployment, kicked off by users from Software Centre, that uses USMT to backup user data. Our company policies are quite liberal and back up potentially large amounts of user data, which can take some time. Does anyone know if there is a script or tool that we might be able to use to inform users, prior to kicking off the OSD Refresh process of just how much data will be captured in terms of file numbers of amount of Gigabytes? It would give users a choice to purge data or back up themselves rather than waiting on SCCM to do it.

I manage windows updates on our server fleet, using SCCM 2012 R2 SP1. Despite having clear-cut Maintenance Windows for our servers, we are still finding cases of individual servers having restarted unexpectedly. In each case, the %Windir%\WindowsUpdate.log shows: The process C:\Windows\system32\svchost.exe (ComputerName) has initiated the restart of computer ComputerName on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Recovery (Planned) Reason Code: 0x80020002 Shutdown Type: restart As for why it restarted, the same log has the segment: Client has determined it is safe to reboot without warning. Rebooting now... This wasn't during a Maintenance Window, mind you. Not all our servers are doing this. I've read online about Windows Update and SCCM and some posters mention that there are possible Group Policy changes that are needed to be made. This surprises me, because I always thought that when you install an SCCM client on a machine, it leverages Windows Update to push out updates, changing Windows Update behaviour to suit what we configure in SCCM. Adding to my confusion is the fact that different server OS seem to have different WIndows Update settings after SCCM client is installed, see attachments. Does anyone have any clues as to why servers might be ignoring maintenance windows in some cases? I can confirm we don't have a case of multiple maintenance windows becoming cumulative or anything like that. Are there any Group Policy settings that users of SCCM have to make in order for workstations or servers to properly follow SCCM's instructions?

Some types of updates can install outside maintenance windows, such as Forefront Definition updates. At least, thats my understanding. Otherwise machines could go a month or more before updating antimalware definitions.

I have installed SCCM client on several workgroup and machines on separate domain to our SCCM infrastructure, with use of ports and certificates. We find that SCCM seems to manage the clients fine, except that the Endpoint Protection appears to die some hours or days later - the definitions seem to fail to come down to the machine and ultimately the Endpoint icon turns red and shows it is turned off. Software Updates via Software Centre are otherwise coming down to the machines without problems - if anyone has any suggestions on what could be causing Endpoint to fail to keep itself active, that would be helpful.

Hi mehraranjit, thanks for your reply. Yes, I was using a manual client install. I'll follow your suggestion and check if I can discover any machines in that same boundary. Although, because the machines are in another domain I may not be able to discover them. I'll also check whether we have a two-way trust or whether it is just a stub zone we are using.

Hi All, I'm very grateful to Niall Brady for providing excellent assistance on how we can install and manage servers in SCCM that are Workgroup machines: http://www.windows-noob.com/forums/index.php?/topic/8977-how-can-i-remotely-control-workgroup-computers-in-system-center-2012-configuration-manager/ However, I'm now trying to get SCCM to talk to servers that are in a separate domain to our SCCM infrastructure. In this instance, the separate domain has a Stub Zone in DNS, so as long as I provide a FQDN, I can resolve the SCCM servers in our domain. I've added the IP subnet of the server in question into Boundaries and associated it with a Boundary Group. I've added recommended entries into LMHOSTS (See the above URL) to help the server identify which SCCM server is the MP and SLP. I've requested and have installed a Security Certificate from our regular domain's CA authority. There is no firewall between the server in other domain and our regular domain. The SCCM client installs, but never seems to recognize the certificate installed on it. I've tried install CCMSetup.exe both WITH and WITHOUT specifying a FSP, but doesn't seem to make a difference. If anyone has any other suggestions that might help, will much appreciate it. Cheers.

Niall, you have saved me! Your documentation spelled out exactly what I was missing - entries in my LMHOSTS file! Once I made the entries, I just had to find an installation command line that worked for our environment. In my case, I had already copied the CCMsetup installation source files over to the workgroup machine and used the following syntax: ccmsetup.exe /mp:{Our MP Server in the DMZ FQDN} SMSSITECODE={Our SMS Site Code} FSP={Our Primary Site Server} After installation, I went into Devices in SCCM Admin Console and voila! Found the Workgroup server in Unapproved state, right-clicked, chose Approve, YES! Thank you so very, very much!

Thanks very much, Niall! Checking out your guide now.

I might also add, I have a certificate in "Personal" folder of the workgroup machine, issued by our Root Certification server for Server communication - can anyone advise whether such a certificate is required for SCCM to talk to servers outside the domain? We originally installed that certificate for SCOM to manage DMZ servers, but I wasn't sure whether SCCM also needed it.

Sorry for delay in responding, but thanks Peter for your contribution. I'll remove the SCCM client from my workgroup machine and reinstall with the modified command line you suggest and see how I go. If you know of any specific logs that will shed light on why a connection may not be established, that would also be handy.

I'll also add that we have a Boundary and Boundary Group defined for the IP range these DMZ Workgroup servers sit in, so that is another bit that should be fine.

Hi All, I am trying to get SCCM client to install and talk to servers that are Workgroup (non-domain joined) and sitting in a DMZ, i.e. outside our regular domain. We have a MP installed in the DMZ that is intended to communicate with devices in the DMZ, domain-joined or not. The DMZ domain-joined machines SCCM clients work fine, its the DMZ workgroup machines that don't. I am installing SCCM client with syntax like: ccmsetup.exe /mp:{MPserver for DMZ FQDN} SMSSITECODE={our site code} FSP={MP for our regular domain} * I have added the IP and hostname of our MP DMZ server into our Hosts file, so the workgroup machine can resolve the hostname of the MP. * Our networks team has confirmed that there are no ports or firewalling blocking communication between the DMZ workgroup machines and our SCCM infrastructure. * We have used our Active Directory Certification Services to install a Personal certificate to allow communicate between the host machine and our SCOM infrastructure. SCOM talks to these machines without issue, but SCCM is not. The repeating errors in LocationServices.log of our DMZ Workgroup machines are as follows: Any tips on troubleshooting?

Hello, Using SCCM 2012 with a Software Update Point. Can someone advise how SCCM determines the "Update Classification" for each update it pulls down from Internet? I ask because many updates being downloaded in our environment are being put in the Update Classification of "Critical Updates", yet the "Severity" of the updates are set to "None". I've been asked to account for which is the case - are these updates truly "Critical" or this a product of how our environment is set up? I attach an example update and a look at our update classification settings.

Query worked when pasted in for me too, although I definitely needed to add a "DISTINCT" to the initial SELECT statement as I had many, many entries for each system found by the query.

So glad you are deploying IBCM and not an ICBM.