Microsoft Forefront Client Security (FCS) server components do not run on 64 bit servers. OK, that's no problem, we will have a dedicated 32 bit server. It should be simple enough, shouldn't it?
Hang on a sec. We have to install the FCS Distribution component to configure the updates on WSUS. The WSUS server is 64 bit, and the FCS Distribution component will not install on it.
OK, let's just install WSUS on the FCS Server. It doesn't matter if we have two WSUS servers bringing down updates, in fact it's quite neat and tidy. We could use the FCS copy of WSUS for FCS updates only.
Hang on a sec. The workstation can only have one WSUS server in Group Policy, and so it has to get its Windows Updates from the same server as FCS updates. That means the FCS server has to become the WSUS server. But we have distributed WSUS servers. That means they all have to get their updates from the FCS server. That's putting the cart before the horse. I thought FCS was just making use of the updates distribution service, but now it is telling me how it has to run.
What is this Distribution component anyway? It only sets the update frequency, adds the Forefront updates to the Product list and sets up automatic approval. We can do that natively in WSUS 3.0. So maybe we don't need it anyway, and can keep the existing WSUS server.
OK, moving on, let's use our existing SQL 2005 Enterprise (this is on 64 bit, by the way). It is good practice to use an off box SQL Server, and it makes good use of an Enterprise license. Wait a minute. We need Reporting Services. And that needs IIS. OK, let's install these on the SQL Server. And Integration Services, because it needs those as well.
Hang on a sec. The Collection database cannot be separated from the Collection server component. And that won't install on 64 bit. And my SQL Server 2005 is 64 bit, so after all I need a dedicated SQL Server, even though I have a perfectly good SQL Server already.
But we can use SQL Express for a small service like this, can't we? Nope, it needs Integration Services and is not supported on SQL Express. I give in. I can't take any more. We'll buy a SQL Standard license, or use the edition with dedicated SQL Enterprise license.
Right. Let's get on with the installation.
What's this? It won't install. But it couldn't be simpler! We are just doing a standard installation on a standard Server 2008 32 bit server. It keeps failing after the pre-requisites check but while creating the Collection database. What can it be? Nothing in the setup log.
We dig deeper into the logs. It is trying to create the database on the C: drive even though we set up SQL to store databases on the D: drive, which is standard good practice. It recognises that the default folder is on D: but changes this to C: There is not enough room on C: so it fails.
OK, lets create a very small database on C: then move it in SQL Server Management Studio to D: and expand it. FCS will be none the wiser. Yup, that's OK. Its just a dumb installer script.
Right, let's get on. We want to get the client onto Windows 7. I assume we are going to install the client, and then tell it where the updates (and security policy) come from. I can create the FCS policy, and use the existing Windows Updates policy. Let's find the latest client. But where is the client? There isn't one. What do you mean there isn't one? I mean there isn't one. You have to install the old client, dated 2007. The WSUS server interrogates the client, checks whether there is a MOMserver setting, and updates it with a newer client. Then the next time round the WSUS server interrogates the client, finds it is newer, and applies all the updates for the newer client. It could take forever! So we need to write a script that tells the client to run Windows Updates straightaway, to get itself up to date after the client is first installed.
Comments