Configuration Manager (SCCM) client push installation fails for a Windows virtual machine in Shared Networking mode

If you use client push to deploy the Microsoft Configuration Manager (SCCM) client to a Windows virtual machine, you may see the following:

• You cannot deploy the Microsoft Configuration Manager (SCCM) client to a Windows virtual machine by using the client push installation method while the virtual machine's network adapter is set to Shared Network.
• The installation completes only after you switch the adapter to Bridged Network.
• With the adapter left in Bridged Network, the installed client does not report to the management point. Check-in resumes after you switch the adapter back to Shared Network.

How Client Push and Parallels Desktop networking interacts

Client push requires inbound access to the endpoint.

Client push is initiated by the site server, not by the virtual machine. To start the installation, the site server opens an inbound connection to the endpoint over SMB (TCP 445) and RPC (TCP 135 plus dynamic high ports), copies ccmsetup to the target, and starts it remotely. The method assumes a flat corporate LAN in which every endpoint is directly addressable.

Parallels Shared Network places the virtual machine behind NAT. The virtual machine has no address of its own on the corporate network, so the site server cannot reach it and cannot start the installation. Endpoints behind NAT are out of scope for client push by design.

Bridged Network excludes the virtual machine from the Mac's VPN connection.

In Shared Network mode the virtual machine's traffic is routed through the Mac's own network stack, so the virtual machine inherits whatever connectivity the Mac has, including an active VPN tunnel. In Bridged Network mode the virtual machine is an independent device on the physical network with its own MAC and IP address, and it is outside the Mac's VPN tunnel. If corporate infrastructure — including the management point — is reachable only over VPN, a bridged virtual machine cannot reach it, and the client cannot check in.

Everything the Configuration Manager client does after installation (policy retrieval, inventory, heartbeat discovery, state messages) is outbound and client-initiated, so it works normally in Shared Network mode. The inbound requirement applies only to the one-time installation.

Recommended Deployment method

Keep the virtual machine in Shared Network mode and pre-install the Configuration Manager client in your Windows template, so that every virtual machine deployed from it enrolls on first boot.

This follows Microsoft's documented OS image installation method and requires no inbound connectivity to the virtual machine at any point.

Prepare the reference virtual machine (once)

Perform these steps in the Windows virtual machine you intend to use as a golden image. Install Parallels Tools and any required applications before you begin, since Sysprep is the final step.

1. Install the client manually from the site share, without a site code:

   ccmsetup.exe /mp:<MP FQDN>
   

   Omit SMSSITECODE deliberately. The image must carry no site assignment.

2. Stop the SMS Agent Host service from an elevated command prompt:

   net stop ccmexec
   

3. Delete C:\Windows\SMSCFG.INI.

   This file holds the client's GUID (SMS Unique Identifier). If it remains in the image, every clone claims the same identity and the clones overwrite each other in the Configuration Manager console. The resulting symptom looks exactly like a client that never checks in.

4. Clear the SMS certificate store. This is a dedicated local machine store, visible in certlm.msc or as Cert:\LocalMachine\SMS. At install time the client places a self-signed certificate there and uses it to sign its traffic to the management point, so it is the second half of the client's identity alongside the GUID.

   Remove-Item Cert:\LocalMachine\SMS\* -Force
   

   If you use PKI, also remove client authentication certificates from the Personal store, for both Computer and User.

5. If the clones will be deployed into a different Configuration Manager hierarchy than the reference virtual machine, remove the trusted root key as well. If they will be deployed into the same hierarchy, which is the usual case, leave the trusted root key in place.

6. Run Sysprep:

   sysprep /generalize /oobe /shutdown
   

   Sysprep has no awareness of Configuration Manager and will not touch SMSCFG.INI or the SMS certificate store. Steps 3 and 4 must be completed manually before Sysprep runs.

Save the result as your Parallels Desktop golden image.

Each virtual machine deployed from this image generates its own client identity on first boot and registers with the management point on its own, over outbound connections only.

Note: Microsoft's article warns that the Prepare ConfigMgr Client for Capture task sequence step removes the client completely. That warning applies to image capture performed by a Configuration Manager task sequence. It does not apply to the procedure above, where you capture the Parallels Desktop virtual machine directly.

Why we recommend keeping Shared Network

• Attack surface. Bridged Network places the virtual machine on the corporate network as an independent device. For client push to reach it, SMB (TCP 445) and the RPC port range must also be reachable inbound on that device. That is additional exposure on the LAN in exchange for a one-time installation step.
• Connectivity for remote users. A bridged virtual machine does not use the Mac's VPN connection. On any Mac that works off-site, the virtual machine loses access to corporate infrastructure, including the management point.
• Consistency. Shared Network behaves the same way on every network the Mac connects to — office, home, or tethered — so no per-location network changes are required.

Port forwarding is not a workaround

Forwarding SMB and RPC ports to the virtual machine in the Parallels Desktop network preferences does not enable client push:

• RPC negotiates dynamic high ports after the initial connection on TCP 135, so a fixed forwarding rule cannot cover the exchange.
• The site server connects to the address it discovered for the endpoint. A virtual machine behind NAT may register its private Parallels address (for example, 10.211.55.x) in DNS, which the site server then cannot reach.
• Each virtual machine on the same Mac would require its own unique set of forwarded ports, which does not scale to a fleet.

Additional Information

Why the installation succeeds in Bridged Network mode

In Bridged Network mode the virtual machine is directly addressable on the network the Mac is connected to, so the site server can complete the inbound SMB and RPC connections that client push depends on, provided the Mac is on the corporate network at that moment. This is why switching to Bridged appears to resolve the problem, and why switching back to Shared afterwards has no effect on the installed client: the inbound requirement existed only for the installation, never for ongoing client operation.

Client identity

A Configuration Manager client's identity has two parts: the GUID stored in SMSCFG.INI, and the self-signed certificate in the SMS store. Both are created at installation time, and both must be cleared before capture. If either is left in the image, all clones share one identity and overwrite each other in the console.