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.

Also make sure that for any applications, under Deployment Type, Content, that in situations of a slow or unreliable link that you choose "Download this content and run locally". That was a problem for us recently, our remote site users couldn't pull down SCCM content. Turns out we had defined all remote sites as being part of a "Remote" Site in Active Directory Sites and Services and that we had explicitically defined the Remote site as being "Slow" in SCCM.

What have you done so far, kdevries? The kind of steps I'd be looking at doing would be: 1. Get iTunes packaged as an MSI if possible. This may mean re-authoring or capturing the iTunes installation using something like Flexera AdminStudio/Wise Installer. Having an installer in an MSI format gives you the ability to install it using Windows Installer, which is very useful and enables consistent installation and uninstallation. 2. On-board the iTunes MSI and any Transform (*.MST) as new Application in SCCM. You would probably want to choose an Application over Package, as it gives more power and flexibility than Packages and would allow users to request iTunes (if thats the way you wanted to go) via the SCCM Self-Service frontend. (Packages don't have that ability) 3. As part of on-boarding iTunes application, in Properties make sure the Application is checked to be available to install by Task Sequences. That may not be turned on by default. 4. Distribute your iTunes application to all your Distribution Points. If you want iTunes available for users to Self-Install instead of being in Task Sequence, make sure you deploy it to a suitable collection of Users as "Available" or whichever your business needs dictate. 5. You'd want to create a Operating System Deployment (OSD) Task Sequence and make sure it does what the label describes, i.e. installing an operating system with your required settings. 6. Once your Task Sequence is working in its own right, edit the Task Sequence and insert "Install Application" somewhere in the process and choose iTunes. Test!

In some cases, depending on how an EXE was written, it may not follow your instruction for it to be hidden when it installs. One idea is to use a program like 7Zip to see if you can extract the contents of the Lenovo Hotkey Integration setup. In some cases, you'll see there is actually an MSI available inside. If you get direct access to the MSI and if it is indeed a healthy, well-constructed MSI, you should be able to make use of MSIEXEC and hide any UI. i.e. msiexec.exe /I {File.msi} /qn! Or similar.

I suggest checking whether any of your device collections have Maintenance Windows set on them. I use a PowerShell script (Link below) to query all my collections and let me know if any have Maintenance Windows set, so I can troubleshoot or prepare to a batch of updates: http://cm12sdk.net/?p=1847

Thanks very much Peter! I'll check our Group Policy for that OU.

Hi All, We are using SCCM 2012 to manage our fleet of workstations and servers. We are using SCCM to manage operating system updates as well. Most of our servers obediently follow instruction by SCCM to install updates when they are supposed to. However, a small number seem to have two sets of update components - Windows Update and SCCM's Updates. If anyone has seen this before, I'd be appreciative to know whether there is a routine we can run to remove any Windows Updates components that are not required, so that it is purely SCCM managing the updates process. Here is an example screenshot showing a server with the two components seemingly on at the same time, prompting for a restart: (Server 2008 R2 in this case)

Hello, After recently restarted our SCCM primary site server for periodic maintenance, we then found that our Desktop team could not build machines using Operating System Deployment (OSD). The machines would boot via PXE and would only proceed to the point where they had to download content. The smsts.log on the machines gave this important line: Failed to resolve the source for SMS PKGID=PR10006D, hr=0x80070002 My first line of investigation was to check that the content used in the Task Sequence was distributed to each of our DPs, it was. I then checked whether the service accounts in Active Directory used for build, capture, network access were enabled and that their passwords hadn't expired or accounts weren't locked, those accounts were fine. I then logged into a server with the credentials of our SCCM Network access account and tried to browse to the location on the DP where packages are stored - it wouldn't let me access that location. This was strange because that account had rights. Ultimately, I found the fix - Our SCCM server is a Windows Server 2012 server sitting in VMWare and the server was set to allow hotplugging of devices, including its hard disks. This seems to cause issues with some applications, including SCCM. To resolve, I followed the steps in this VMWare KB article to turn off the hotplug settings: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012225 To make this change, I had to power off our SCCM server, but the change itself was quick and once the server was back, Windows was no longer treating the disks as removable and suddenly content on the server was accessible for OSD, Windows Updates, etc. I just thought I'd share this topic if anyone else runs into this issue.

Hello All, I am happy to advise this issue of my ADRs not downloading certain updates appears to be resolved. How - restarting our SCCM server. I regret not trying this earlier, but I try to avoid seeing a restart as a fix - I think I'll try this as an initial step next time I get something like this occurring. Ocelaris, thanks for your assistance. Daniel V

Hi LaurentDew, just letting you know I have the same error when I try to download updates manually and import them using SCCM. I'm having a separate error whereby some of the content of the updates in SCCM aren't downloading for some reason. We think its a proxy-related issue in our case, which is why I tried downloading the missing updates manually. I hope others see your post and assist, as this is causing issues for us.

Ocelaris, another excellent suggestion, sorry about the delay responding. I appreciate your effort. I DO suspect my issue is proxy-related, so I'll try your steps now.