Tips, Tricks & Hints for Native Mode and Internet-Based Client Management - Part 1 of 3
Since the November release, my writing time has been devoted to the new “out of band management” feature in SP1, but I’ve also spent a lot of time helping customers install and test native mode and Internet-based client management in both test and production environments.
Overall, I’m really impressed with how many successful implementations there have been because I fully admit native mode is not an easy deployment – not helped by PKI being a new technology to many SMS administrators, also trying to get to grips with all the new things in Configuration Manager. Kudos to you!
Although my official writing time has been spent on the soon-to-be released beta 1 SP1, I rounded up some of the native mode and Internet-based FAQs and gotchas I’ve recently come across to share with you, and hopefully provide some additional information that might help you with your implementation of native mode and Internet-based client management.
And for those of you intrigued by what the new out of band management feature has to offer in SP1, I’ll write up another blog entry as a quick introduction to help you decide if this is something you want to consider for the future, and whether you want to check it out in B1.
Tips, tricks and hints covered:
Part 1 of 3
- You can’t run a native mode client on Windows 2000
- Don’t install clients using auto-site assignment and specify the Internet-based management point
- You can’t use a single Internet-based management point for multiple primary sites
Part 2 of 3
- “We have a security policy that no traffic from the DMZ is allowed towards servers on the intranet. Is there an IBCM design that supports this?”
- Certificate configuration for Internet-based site systems on the intranet that only manage mobile device clients
- The option “Specify or modify a DNS suffix for site assignment” has nothing to do with site assignment
- The behavior of CCMFIRSTCERT=1 (option “Select any certificate that matches”) is changing in SP1
Part 3 of 3
- CRL complications for Internet-based client management
- “Can you update the step-by-step to include ….?”
You Can’t Run a Native Mode Client on Windows 2000
If you hear that native mode isn't supported on a Win2K client, it doesn't mean that it probably works but isn't fully tested. It means it doesn't work. This is clearly documented, but some customers are missing it, migrating the site to native mode and then finding their Win2K clients unmanaged. To be honest, we didn’t think many customers would be affected by this restriction because Win2K is outside mainstream support from Microsoft (although still supported for Configuration Manager clients). However, the following important note is listed in the topic Prerequisites for Native Mode:
Client computers running Windows 2000 Professional or Windows 2000 Server cannot support native mode and will be unmanaged if they are assigned to a site that is configured for native mode.
It’s also listed in the topic Choose between Native Mode and Mixed Mode:
Choose native mode if any of the following conditions apply:
· You require the highest security controls, using industry-standard protocols.
· You require Internet-based client management.
Choose mixed mode if any of the following conditions apply:
· You do not have the supporting Public Key Infrastructure (PKI).
· You have not installed the specific certificates required by Configuration Manager 2007.
· The site contains SMS 2003 clients.
· The site contains clients running Windows 2000 Professional or Windows Server 2000.
· The parent site is configured for mixed mode.
· Site systems running Internet Information Services (IIS) are not dedicated to Configuration Manager, and you cannot configure a custom Web site.
· You must use WINS as the means by which clients can find their default management point.
· You do not want the site's secondary sites to be automatically migrated.
For the SP1 documentation, we’ve also added this information to the "Supported Configs" topic (Configuration Manager Supported Configurations) to help with visibility of this restriction – although Windows 2000 continues to be supported for Configuration Manager clients. The restriction is that native mode doesn’t work on Windows 2000.
We won’t be adding this to the topic Prerequisites for Configuration Manager Client Deployment (where some customers have said they expected to see this restriction listed) because it’s not a prerequisite for client deployment. The client installs just fine on Win2K, even if the installation properties directly configure native mode communication (rather than installing the client in mixed mode and the client dynamically reconfigures to native mode from the site properties published to Active Directory Domain Services).
In case you were wondering why there’s this restriction for native mode on Windows 2000 when the product itself supports the operating system for clients, it’s not our restriction but one that is imposed on us because native mode uses BITS 2.5 or higher - and Win2k only supports up to BITS 2.0.
If you have installed the client on Win2K and it’s assigned to a native mode site, your options are:
Upgrade the OS. Admittedly this might not be an immediately viable solution for most customers in this scenario, but from a Configuration Manager perspective it is the best solution. However, because of the BITS 2.5 requirement, you might have to reinstall the client or install BITS 2.5 out of band after the operating system upgrade.
Reassign the client to a mixed mode site. If you have just a few Win2K clients and the disadvantages of reassigning them outweigh the advantages of the site being in native mode (for example, to support Internet-based client management), then this could be an administrator’s best solution for this scenario.
Revert the site to mixed mode. Yes, this is technically possible and supported, but don’t choose this option lightly – especially on a production network. You might have heard expressions like “move the site mode back and forth” and although it is a simple-click procedure in the UI, you shouldn’t consider the site mode option like a light switch. The product team considers reverting the site mode as a last resort, not a repeated procedure, so bear this in mind. Although the UI configuration takes just a couple of seconds, the backend processes can take a full day or more to complete, during which time your clients could be unmanaged. And if you have clients that can’t access site information in Active Directory Domain Services, they will not automatically reconfigure for mixed mode and you will need to reinstall them. For procedural information to revert the site mode, see How to Revert a Configuration Manager Site to Mixed Mode. To monitor which site mode a client is currently using, see How to Monitor Changes in Configuration Manager Client Site Modes. It’s not a requirement (or a recommendation) to remove the native mode certificates.
At the risk of sounding like a broken record: Please, please check the prerequisite topics before implementing a feature in Configuration Manager to avoid a frustrating experience at best, and a career-limiting move at worst. Unfortunately there are a lot of prerequisites in Configuration Manager: don’t assume everything will just work if you don’t get warning or error messages from the product.
Don’t Install Clients using Auto-Site Assignment and Specify the Internet-Based Management Point
We’ve had a couple of reports of customers who want to use both auto-site assignment and Internet-based client management. So they install clients with the CCMHOSTNAME property to specify an Internet FQDN for an Internet-based management point, together with SMSSITECODE=AUTO. This combination does not work, although CCMSetup isn’t smart enough to tell you. The client installs just fine, but fails to assign. We’ve filed a bug to fix this in the future (so that CCMSETUP recognizes these two properties together are not valid and fails to run), but it won’t be fixed in SP1.
We have updated the SP1 documentation to warn customers that combining these two installation properties does not work, although the following is stated in the topic About Client Site Assignment in Configuration Manager:
Configuration Manager 2007 clients cannot be automatically assigned to a site if any of the following scenarios apply, and instead they must be manually assigned:
· They are currently assigned to a site.
· You want to manage them as Internet-based clients.
· They will locate the site's default management point using DNS publishing
· Their IP address does not fall within one of the configured boundaries in the Configuration Manager hierarchy.
Site assignment has changed quite a bit in Configuration Manager, so it pays to check out this topic rather than assuming that SMS 2003 behavior still applies.
So why doesn’t this combination work? When you install the client and specify the Internet-based management point, the client doesn’t retrieve any site information (it skips the site compatibility check). Site information is stored in Active Directory Domain Services and can also be retrieved from the server locator point. When a client is installed on the Internet, it can’t access either of these, so it skips retrieving site information. When the client is installed on the intranet, at this point it doesn’t know whether it’s on the Internet or the intranet (the detection method it uses is whether it can contact its default management point, which is only possible after site assignment succeeds). So site information is also skipped when the client is on the intranet.
Site information includes the site boundary information that’s needed for auto-site assignment to succeed – hence auto-site assignment fails if the client isn't checking site information.
When we’ve confirmed with customers that you can’t install clients using these two properties, they are unhappy that they can’t have a single installation script for all clients, and have to define in advance which site a client will be assigned to. However, for Internet-based client management you have to define the FQDN of the Internet-based management point, and to do this successfully at installation, you need to know which site the client will be assigned to. You can’t share a single Internet-based management point between sites (see next point listed).
Accepting that auto-site assignment isn’t possible when you’re installing a client that is actually on the Internet, what options are there if you want to simplify configuration for Internet-based client management when the client installs on the intranet? Well, this isn’t official advice from the product team but in thinking this through, I came up with the following:
- Install clients using auto-site assignment (assuming none of the other scenarios listed above apply) and do not specify the Internet-based management point. Create a script for each site that supports Internet-based client management that reinstalls the client with the site code and the CCMHOSTNAME property, and advertise this to run once so that the client runs it after assignment succeeds and it downloads its client policy.
- Install clients using auto-site assignment (assuming none of the other scenarios listed above apply) and do not specify the Internet-based management point. Create a script for each site that supports Internet-based client management that configures the Internet-based management point and advertise this to run once so that the client runs it after assignment succeeds and it downloads its client policy.
The second option involves calling a method that's documented in the SDK. However, not everybody is a scripting expert (and I certainly count myself in this bucket) so I asked our helpful and knowledgeable SDK writer, Jim Bradbury, if he could provide a sample script and he provided me with the following. Obviously, you will need to tweak this – for example specify your own FQDN for the site’s Internet-based management point, and you will probably want to run it silently on clients rather than display the before and after values for confirmation. Copy it, save it with a .VBS extension and then run it using cscript.
!! Warning: This script has not been fully tested and is provided with no warranties or guarantees !!
On Error Resume Next
' Create varibles.
Dim newInternetBasedManagementPointFQDN
Dim client
' Set variable with the FQDN (this will be used to set the Internet-Based Management Point FQDN).
newInternetBasedManagementPointFQDN = "mp.contoso.com"
' Create the client COM object.
Set client = CreateObject ("Microsoft.SMS.Client")
' Output the current Internet-Based Management Point FQDN by calling the GetCurrentManagementPoint method.
WScript.Echo "Current Internet-Based Management Point FQDN is : " & client.GetInternetManagementPointFQDN
WScript.Echo " "
' Set the Internet-Based Management Point FQDN by calling the SetCurrentManagementPoint method.
client.SetInternetManagementPointFQDN newInternetBasedManagementPointFQDN
' Output the current (new) Internet-Based Management Point FQDN by calling the GetCurrentManagementPoint method.
WScript.Echo "Current Internet-Based Management Point FQDN is now : " & client.GetInternetManagementPointFQDN
WScript.Echo " "
' Clear variables.
Set client = Nothing
Set internetBasedManagementPointFQDN = Nothing
To make sure that your clients are configured correctly, you can run a query to display the Internet-based client management point from hardware inventory using the query documented in How to Identify Client Configuration Details for Native Mode and Internet-Based Client Management.
You Can’t Use a Single Internet-Based Management Point for Multiple Primary Sites
Some customers have incorrectly assumed that they could configure just a single site for Internet-based client management that could then be used by all clients in the hierarchy, regardless of which site they were assigned to.
I can fully appreciate why you would want to do this, but Internet-based client management doesn’t support this design. For each client that you want to manage over the Internet, that client’s primary site has to be configured for Internet-based client management and the client has to be assigned to the Internet-based client management point in that site. There is no backend mechanism for the client to automatically locate its site’s Internet-based management point like there is for the default management point on the intranet – so it has to be manually assigned.
Additionally, there is no concept of “roaming” on the Internet – and I suspect misunderstanding how roaming works might be why some customers made this wrong assumption about sharing an Internet-based management point. Roaming allows a client to find the closest distribution points and although it might do this by communicating with the resident management point (if the client has global roaming capability), a roaming client will always contact a management point in its assigned site (either the default management point or a proxy management). If you think about this logically, this makes sense. You wouldn’t want a roaming client to get policy from a different site.
If you need a primer on what’s actually going on when a client roams to another site, which site systems it communicates with for what, see Example Roaming Scenarios for Configuration Manager: Simple.
So, if you need to manage clients over the Internet and they are assigned to multiple primary sites, your options are one of the following, or a hybrid of these:
- Reassign clients to a single site that will be configured for Internet-based client management.
- Configure all these primary sites for Internet-based client management, and assign the appropriate Internet-based management point from these sites to the clients.
- Carol Bailey
This posting is provided “AS IS” with no warranties and confers no rights.
Comments
Anonymous
January 01, 2003
This is the final part of my round-up to date of FAQs and gotchas for native mode and Internet-basedAnonymous
January 01, 2003
If you're interested in Configuration Manager native mode sites supporting Internet-based clientsAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
This is the second part of my round-up to date of FAQs and gotchas for native mode and Internet-basedAnonymous
January 18, 2008
The comment has been removed