Last week I did some ConfigMgr client installation on DMZ workgroup servers. Installation of the client went fine, but they went on internet mode after that. There was no possibility to add them to a Site either. Looking in locationservices.log the following lines were showed:
-Failed to resolve 'SMS_SLP' from WINS
-Unable to find lookup MP(s) in Registry , AD, DNS and Wins
-LSIsSIteCompatible: Failed to get Site version from all directories.
-failed to get dp locations as the expected version from mp
The installation line used was as follows:
Ccmsetup.exe /mp:<FQDN> /logon SMSSITECODE=XXX FSP=<FQDN>
After a few installations I found the following website:
About Client Installation Properties in Configuration Manager 2012
It mentions:
/source:<Path> = Specifies the location from which to download installation files. You can use a local or UNC installation path. Files are downloaded by using the server message block (SMB) protocol.
/mp:<Computer> = Specifies the source management point for downloading installation files. Files are downloaded over an HTTP or HTTPS connection, depending on the management configuration for client connections. This download uses BITS throttling, if BITS throttling is configured. If the management point is configured for HTTPS client connections only, you must verify that the client computer has a valid PKI client certificate.
/logon = Specifies that the client installation should stop if any version of the Configuration Manager 2012 or SMS client is already installed.
SMSMP = Associates the Configuration Manager 2012 client with the specified management point. You can specify a fully qualified domain name as this property.
In the end I used the following installation line to install ConfigMgr 2012 Clients on DMZ workgroups servers successfully:
Ccmsetup.exe /source:<path> SMSSITECODE=XXX FSP=<FQDN> SMSMP=<FQDN>
Hope it helps!
Source:
Install SCCM 2012 Client on DMZ workgroup servers
Managing workgroup clients in Configuration Manager 2012
Within ConfigMgr both Domain joined and Workgroup systems can be managed. Most prefered way is Domain joined probably, where systems are trusted automatically and updated after every deployment. Still Workgroup systems are used at customers also, where you must think about local permissions and non-trusted systems. Let's have a look at my experiences so far..
When deploying Domain joined systems, the existing object in ConfigMgr is updated everytime. When looking in Resource explorer you will see History of hardware and software specifications. Domain joined systems will be trusted automatically by default. No need to think about local permissions, because ConfigMgr can install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Active Directory is used to locate management points which is very handy.
When deploying Workgroup systems, a new object in ConfigMgr will be created everytime by default. The old object will get obsolete and History of hardware and software specifications will be lost. Workgroup systems are not trusted by default, or you must choose to change that in Site Hierarchy settings. You need local permissions for sure because there's no way to install the ConfigMgr client remotely or replicate domain account(s) to the Remote Control Users group. Management points cannot be located by Active Directory.
You need a Network Access account on Workgroup systems:
-This account is used by client computers when they cannot use their local computer account to access content on distribution points. This account might also be used during OS deployment when the computer installing the OS does not have a computer account on the domain.
-For ConfigMgr 2012 R2 only: You can now specify multiple network access accounts for a site. When clients try to access content and cannot use their local computer account, they will first use the last network access account that successfully connected. ConfigMgr supports adding up to ten network access accounts.
Source: Microsoft TechNet
Let's have a look at limitations for Workgroup systems:
-Workgroup clients cannot locate management points from Active Directory Domain Services, and instead must use DNS, WINS, or another management point.
-Global roaming is not supported, because clients cannot query Active Directory Domain Services for site information.
-Active Directory discovery methods cannot discover computers in workgroups.
-You cannot deploy software to users of workgroup computers.
-You cannot use the client push installation method to install the client on workgroup computers.
-Workgroup clients cannot use Kerberos for authentication and so might require manual approval.
-A workgroup client cannot be configured as a distribution point. ConfigMgr 2012 requires that distribution point computers be members of a domain.
Source: Microsoft TechNet
In my opinion it's way better to handle Domain joined systems when management must be done after deployment. More stable and easier for quick communication. There are a few tricks however to get things automated. Just have a look at them for more information:
-Remote Control on Workgroup systems
-Client Push Installation on Workgroup systems
-Support on Workgroup systems
