Recently, a client sent in a request to do just what the title of this blog says: Install the SCCM agent on their Azure VM, which isn’t domain joined and has firewall restrictions. Being away from SCCM for the past few years has left me with memory gaps. I knew I needed to run the installation locally, but I had never really tried to manage a workgroup machine with SCCM. I tried copying the installation files to the machine, but that didn’t work.
I tried the following combo directly from the TechNet site (modified for my environment, naturally):
ccmsetup.exe FSP=sccmserver.yourdomain.com /MP:sccmserver.yourdomain.com SMSSITECODE=ABC DNSSUFFIX=yourdomain.com
The piece that is really important here is the DNS suffix. Since the machine isn’t joined to the domain and in Azure, it likely won’t resolve the server address without using the FQDN. However, we all know nothing from the Microsoft site works as advertised. Amirite!? After multiple iterations and failures, I did some digging and eventually figured out the missing link. (And no, we’re not talking about the old wrestler.)
This may or may not have been how I felt trying to figure this out.
The magic code that finally got this to work is:
ccmsetup.exe FSP=sccmserver.yourdomain.com /MP:sccmserver.yourdomain.com SMSSITTECODE=ABC DNSSUFFIX=yourdomain.com /SOURCE:C:\LOCAL\SOURCE\PATH
Without that switch, the installer will try to reach the site server specified and download the installation files, even though you’re launching them from a local source! This is problematic in any cloud environment, primarily because of firewall issues.
Then the network guy opened up the 8530 and 8531 ports from the Azure VM to the site server and approved the agent in the console. And with that, I was all done.
Using this procedure, you can now install your agents hassle-free and manage your standalone workstations in the cloud with your on-prem SCCM server!