I was preparing to roll out SQL Server 2016 and Windows Server 2016 and had deployed the first server in production. I suddenly noticed that even if I selected “Check online for updates from Microsoft Update” in the horrible new update dialog, I never got any of the additional updates. Btw, this link/button only appears when you have an internal SCCM or WSUS server configured. Clicking the normal Check For Updates button will get updates from WSUS.
This was working as expected in the lab, but the lab does not have the fancy System Center Configuration Manager and WSUS systems. So of course I blamed SCCM and uninstalled the agent. But to no avail, still no updates. I lurked around the update dialog and found that the “Give me updates for other Microsoft products..” option was grayed out and disabled. I am sure that I checked this box during installation, as I remember looking for its location. But it was no longer selected, it was even grayed out.
This smells of GPOs. But I also remembered trying to get this option checked by a GPO to save time during installation, and that it was not possible to do so in Win2012R2. Into the Group Policy Manager of the lab DC I went…
It appears that GPO management of the Microsoft Update option has been added in Win2016:
This option is not available in Win2012R2, but as we have a GPO that defines “Configure Automatic Updates”, it defaults to disabled.
Alternative 1: Upgrade your domain controllers to Win2016.
Alternative 2: Install the Win2016 .admx files on all your domain controllers and administrative workstations.
Then, change the GPO ensuring that “Install updates for other Microsoft products is enabled. Selecting 3 – Auto download used to be a safe setting.
Alternative 3: Remove the GPO or set “Configure Automatic Updates” to “Not Configured”, thus allowing local configuration.
This tool was created as a quick fix for a problem a coworker had in System Center Configuration Manager (SCCM): moving a re-imaged computer to it’s final location. I don’t really know all that much about SCCM, but his problem was to find a script that was able to move the current computer to a new OU based on a special environment variable defined in the task sequence (OSDDomainOUName).
We tried to utilize several vb scripts he found searching the web to no avail. In the end I got tired of this and created a small command line interface to one of my existing code libraries who already had the ability to move a computer.
As usual, this tool is provided without any warranty whatsoever. Use at your own risk, and don’t blame me if it doesn’t work. My coworker has deployed it in production successfully, but I can not guarantee that it will work in your environment. Constructive comments are appreciated, but I can’t promise a swift reply.
The tool itself is fairly simple to use, albeit not necessarily easy to integrate into SCCM. It has two command line options, but in the typical scenario you will only use the /D: for destination. The destination is the name of the OU you want to move the current computer to in FQDN format, e.g. LDAP://cn=ou,DC=test,DC=local. This will typically be collected from the %OSDDomainOUName% environment variable mentioned above.
You can use the /S: option to move another computer than the one you are currently executing the program at.
The user executing the program need to have the necessary domain permissions to perform the operation. In short, domain admin or at least delegated admin for the OUs in question.
The self extracting exe below contains a msi setup package that can be installed (and later uninstalled) as part of the task sequence. If you wish, you can just copy the .exe and .dll files and it will usually work.
In SCCM, you have to define the OSDDomainOUName variable for each collection were you want to use this tool. Then, you have to add a step for running the command AFTER the “Set up Windows and Configuration Manager” step. See screenshots for an example.
Dersom du har fått installert System Center Configuration Manager klienten på en maskin som ikke skal/bør ha slik klient, feks. på et databasecluster, kan det være greit å kunne fjerne den igjen. Først kan det være en ide å sjekke om den faktisk er installert. Den ligger nemlig ikke i legg til/fjern programmer, men man kan lett identifisere den ved å se etter tjenesten SMS Agent Host:
For å fjerne den igjen kjøres følgende kommando i et elevated command prompt:
Hvor denne filen ligger er dog en annen sak. Det avhenger av hvordan CCM er installert, og hva slags OS man har. På 32bit er det vanligvis en mappe kalt %SYSTEMROOT%\System32\CCMSetup, på 64 bit os kan det variere litt, men vanligvis en av følgende:
Om man ikke finner den kan man referere til et nettverksshare på CCM serveren. Hva det heter må få fra de ansvarlige for løsningen (dersom det ikke er en selv), eller man kan være utspekulert søke opp filene selv