I know that I’ve left the Active Directory series with barely enough info to get you going with Linux, but real life priorities are intervening at work, and I don’t have the time right now to document the next step in the Linux integration, which will be getting service level authentication working with Kerberos for stuff like NFS. It’s coming soon, I promise.
In the meantime, I’m setting up another Microsoft System Center Configuration Manager server — for obvious reasons, I won’t use the full title again, and will call it ConfigMgr or SCCM as the mood strikes me — and I thought I’d do a quick write-up on that while I’m at it; while this installation is going smoothly (fingers crossed) I think I reinstalled my original ConfigMgr server four to six times before getting it right.
ConfigMgr Server Setup
To keep things simple, I’ve kept all of my ConfigMgr-related features on one server — the Certificate Server, SQL Server, IIS, and all of ConfigMgr’s own functions are on one box. It seems to handle the load just fine, though the admin interface can be a little sluggish at times when dealing with heavy database interaction.
First of, there’s a question of the version of Windows to use. While I’m almost always inclined to use the latest version of software that is available, my experiences a year or so ago with ConfigMgr on Windows Server 2008 were less than stellar. I spent quite a lot of time running into inexplicable dead ends, and time to waste is not a luxury I have right now. So I’ve decided to continue with Windows Server 2003 R2, which is the next best thing. Once all my new systems are up in production, I’ll go back to the lab and see if the situation with ConfigMgr on 2008 has improved.
The edition of 2003 also matters — you need at least one Enterprise Edition server in your domain running AD Certificate Services, or you won’t be able to even install ConfigMgr without a lot of ugly hacks — it requires a custom certificate template for the SCCM site servers, and Standard Edition won’t let you use custom templates. Also, though I installed 2003 R2, I didn’t ever actually go through the R2 specific features; I didn’t need them on this particular server.
One the system is built, joined to a domain, and patched, I installed IIS. BITS and WebDAV are important requirements, so make sure to install them. Once these were installed, I went back into the Windows Component wizard and installed Certificate Services. I set it up as an enterprise root CA — if you’re deeply concerned about the security of your PKI, you probably don’t want the root CA to be on a production system, but rather on a box which stays offline and physically secure. However, the only purpose of this particular PKI is to provide security for my ConfigMgr setup, so I didn’t see much point in investing significant resources in making it more secure than the overall Active Directory domain which it plays a comparatively small part in. Next I configured the CA and enrolled the ConfigMgr server for its Site Server certificate. This is a bit of an arbitrary and tedious process, so I’ll just point you to the KB article that describes the process. The IIS server should also be configured with a certificate to use for https:// communications — I used a commercial certificate, but you can also use your local PKI to create one. If you choose the latter, domain clients will automatically trust the cert, but non-domain machines will not. This is probably not a big deal, since any non-domain ConfigMgr clients will have to have the PKI root certificate installed anyway, but it’s worth noting in case you’re using standalone systems with the web interface.
The next thing to install is SQL Server; I used 2005, again primarily because of a lack of testing time; when I first installed ConfigMgr, 2005 was the latest version, so I know that it works. Service Pack 2 is definitely required, and there’s a hotfix that I needed; your mileage may vary. WSUS must also be installed, although it doesn’t have to be used for ConfigMgr to deploy patches; I installed it along with SP1, and then took a break from software installations to catch up on patches through Windows Update; a couple of reboots later I was ready to keep forging on ahead, and we were finally done with prerequisites and ready to tackle ConfigMgr itself.
Well, almost ready; technically, extending the AD schema to enhance ConfigMgr support is not required, but it does improve the efficiency of your site, so I decided to go for it; Microsoft has several TechNet articles with more information on why and how to extend the schema — it was completely painless in my case. There wasn’t much to the actual SCCM installer once I’d gotten all of the prereqs out of the way — I chose to do a native mode installation, enabled all agents except for Network Access Protection (again, a feature I haven’t had time to experiment with in a lab), and that was pretty much it. once it had the information it needed, the installer took quite a while to run, so I suggest locking the console and stepping out for a bit of your preferred caffeine source at this point.
After the install itself, I again ran Windows Update, and rebooted, then started up the New Site Roles wizard. A couple of things to keep in mind — the FQDN for inter- and intra- site communication needs to match the Active Directory domain; this might not be an issue for you, but in my environment most of our servers have internet-facing DNS addresses which are shorter that their fully-qualified AD DNS domain. Since the local PKI will be securing the communications, the AD domain name is the one which will be used, and mismatches definitely won’t be accepted. I also instructed the wizard to “use this server as the active software update point”, and checked the boxes for the following roles, keeping with my “one server to rule them all” philosophy:
- Server locator point
- Reporting point
- Software update point
- Fallback status point
The next configuration step was to enable inter- and intra- site communication on both the Management Point and Distribution Point. I also created two domain accounts — one user account with minimal access, which ConfigMgr uses to authenticate when pulling data from the server (the Network Access Account) and one with domain admin which is used to do automated installs; strictly speaking, this account might only need local admin on all of your systems, but it seemed easier to me just to go with domain admin and not worry about the one-off problems that might occur with systems not getting the memo about the account’s access. I also added the ConfigMgr server’s computer account (SERVERNAME$) to the domain admins group — this allows the server, which runs as LocalSystem, to do pretty much anything it wants. This may seem scary, but again, keep in mind that as long as you practice the same level of physical and electronic security measures on this server as you do on your domain controllers, you’re really not introducing a new level of vulnerability, you’re just confronting it from a different angle. Like your domain controllers, this server now holds the keys to your electronic kingdom, so treat it with respect and care! The last set of ConfigMgr settings I had to muck with was under the Software Update Point properties:
- Active software point on site server
- Allow both inter- and intra- communication
- Checkmark “All Classifications”
- Enable synchronization on a schedule
- Uncheck all languages except English
Obviously the last item was specific to my locale; adjust accordingly. At this point, if you’ve enabled client certificate enrollment (as described in the KB article above) and you enable Active Directory discovery and some form of client installation (I do scheduled pushes through ConfigMgr) you should start to get domain clients joining your system.
Manual Client Installation
Manual client installation is a bit of a hassle, but it’s great for supporting users who don’t live on your domain, whether they be home users, laptops, or for little pockets of machines that have to be managed but just can’t be in your primary Active Directory hierarchy.
Before you try to sign up clients, you’ll need to get them into your PKI; the normal Computer certificate isn’t ideal, since it doesn’t allow you to specify the client’s name. Mimic the steps required to create the ConfigMgr Site Server certificate template, but don’t make any changes to the template other than setting the Subject Name to be supplied in the request.
The first thing to do on each client is to get the PKI root certificate into your computer’s local certificate store. If you use the local PKI for IIS on the ConfigMgr server, then simply browse to https://[fqdn]/certsrv, examine the certificate chain that’s presented, and install the Root CA certificate. Once this is done, log in to the address you just visited with a domain admin account, and create a certificate using the template you just set up above. Make sure that the subject name is unique — it doesn’t have to be the FQDN of the system, nor even to be formatted as a DNS name, but if two systems get certificates with the same subject name, only the most recent system will be able to talk to ConfigMgr. Anyhow, once the certificate is installed, get access to the \SMS_SITE\Client folder — via CD/USB drive, network share, whatever, open a command prompt in the folder, and run the following command:
ccmsetup /forcereboot /noservice /native:FALLBACK SMSSITECODE=[sitecode] CCMHOSTNAME=[server.fqdn] FSP=[server.fqdn]
Be prepared for the system to reboot itself with no warning — if this is unacceptable, omit the /forcereboot switch, but remember that the ConfigMgr client probably won’t run until the system is rebooted.
