>During my installation of System Center Configuration Manager 2007, I intentionally had the Active Server Pages setting to Prohibited in IIS 6.0. This is because I always limit my configuration to only those that I use. Since I assumed that .NET 2.0 is required to install SCCM 2007, I was assuming that it is using ASP.NET 2.0 in the reports. To my surprise, when I launched the Virtual Machine provided for the online virtual hands-onlabs, the URL contains a .asp?some_value. Being a part-time developer as I am, my instincts tell me that I need to Allow Active Server Pages on my IIS for this feature to work. I just don’t understand why Microsoft opted for classic ASP when they already have a rich-feature set available from ASP.NET 2.0 to use for generating those reports.
After installing System Center Configuration Manager 2007, we need to deploy the SCCM client. There are a lot of ways to deploy the SCCM client but I will be focusing more on using the Software Update Point as I have been using Windows Server Update Services (WSUS) for patch management. The first thing you need is to make sure that you already have a WSUS 3.0 in your infrastructure as you will be using this as your Software Update Point. The nice thing about this approach is that you already have your infrastructure set for software update management.
- Install Software Update Point.
You need to install the Configuration Manager Software Update Point Site Role on top of your WSUS 3.0. This could also be on another machine which points to a remote WSUS 3.0. If you are going to install this on a server separate from your WSUS 3.0 server, you need to have the WSUS 3.0 admin console prior to installing the software update point. If you want to use your primary site server as your software update point as well, you just need to add a new role and define it as a Software Update Point. The typical configurations for WSUS 3.0 will be used for this configuration, such as if you are using a proxy server to connect to Microsoft Updates, whether you are using an upstream WSUS 3.0 server, etc. You can also enable a synchronization schedule. A recommended schedule for this is on a weekly basis and after patch Tuesday (Tuesday afternoon my time). In my case, I do manual synchronization and run once after patch Tuesday or anytme I get an email alert from Microsoft for Critical Security updates. You also define the classification – critical updates, service packs, etc. – the same way you do in WSUS. Then you specify the products which you need to configure the updates for. Since you have Microsoft as the vendor by default, you can select which products are installed within your enterprise – Office 2003, SQL Server, Windows, etc. Then, you specify the different languages you need for those updates.
Note that the steps are similar to that of the WSUS 3.0 configuration. If you have configured yor WSUS 3.0 prior to deploying your software update point, those will be overwritten by your new configuration.
- Validate your configuration in the Software Update Point Component
Any configuration you’ve made in setting up your software update point can be validated in the Software Update Point Component under the Component Configuration. So, if you need to do some modifications in the long run, this is the right place to do it.
- Configure the Software Update Point Client Installation
At this point, we still have to deploy the SCCM client in order to use our software update point for patch management. Under the Client Installation Methods, make sure that Software Update Point Client Installation is enabled. This is to publish the SCCM client to WSUS 3.0 as a mandatory update. Together with this, the appropriate BITS component will be downloaded by the client as well.
- Configure the Software Update Client Agents
Although we haven’t really installed the SCCM clients at this point, we can already configure how our clients will behave like enforcing all mandatory deployments and deployment re-evaluation
- Configure a Group Policy for Windows Update
Similar to how we configure a group policy to point clients to download updates from a WSUS server, we need to do the same. If you already have this in place, you can skip this portion. For a more detailed description on how to do this, check out this Microsoft TechNet documentation. Make sure that you treat servers and workstations differently so you definitely need separate GPOs for these.
- Import the SCCM 2007 ADM Template
I got this from Kim Oppalfen’s (Microsoft MVP for Software Distribution) blog so all credit goes to him on the ADM template and the process on how to do this. Just make sure you specify the parameters needed for this. In my case, I just used the SMSSITECODE=value parameter.
Now, we’re ready to deploy the SCCM client and our Software Update Point has been configured as well. It’s like hitting two birds with one stone. The best way to test whether our configuration is to log in to one of the machines in your domain and run a group policy update (gpupdate /force for Windows XP and Windows Server 2003 or secedit /refreshpolicy machine_policy /enforce for Windows 2000) and manually run a force detect of the Windows Update client (wuauclt /detectnow) If you open your Task Manager, you will see ccmsetup.exe in the Image name under the Processes tab. Another way to find out if the SCCM client is being deployed thru WSUS 3.0 is to look at the WindowsUpdate.log file which contains information regarding the installation of Configuration Manager Client
I am building my image to test System Center Configuration Manager 2007 (SCCM). SCCM 2007 is the next generation SMS 2003 and is currently on RC1. Since I was responsible for maintaining the WSUS server in our infrastructure, I decided to take a peek at what SCCM 2007 has got to do with making my life easier with patch management. I’ve listed down a few things I did to prepare for SCCM 2007 installation.
- Windows Server 2003 SP1, SP2 or R2
Since I was doing a fresh installation, I chose Windows Server 2003 and installed SP2, although you can do this on a Windows Server 2008 as well. This will act as my domain controller, my database server, my WSUS 3.0 server and my SCCM 2007 server. In a typical setup, you would want to offload your SCCM 2007 and have a separate WSUS 3.0 server and database server (I am assuming that you do not want to run anything on your domain controller machine aside from AD).
- IIS 6.0
You need to install IIS 6.0 if you want to take advantage of BITS technology for clients on low bandwidth connection. There are a lot of reasons for using IIS and this is just one of them. Make sure to enable WebDAV and install BITS Extensions for IIS. I’ve learned this the hard way as my SCCM 2007 installation was not making any progress because of this. Since I was concerned about security, I did not install those components which I don’t need (ASP.NET, SMTP, FTP, NNTP, etc.) The ASP.NET version which I need is v2.0. The one which comes with Windows Server 2003 is v1.1. Another reason I am installing this first before any ASP.NET 2.0 component is that I no longer have to do anything related to ASP.NET 2.0 later on (like running aspnet_regiis.exe -i to install ASP.NET v2 on IIS). We just need to allow ASP.NET 2.0 later on in IIS after installing SQL Server 2005
- SQL Server 2005 with SP2
This will be my database server. Since SQL Server 2005 comes with .NET Framework 2.0, this takes care of my ASP.NET 2.0. Now since I will also host my WSUS 3.0 server on this machine, I can use this as the database server as well. Most of the time, I would work on different instances to identify which one is for what function since SCCM 2007 and WSUS 3.0 would require a database server. For this particular setup, I will just install one instance which will be used by both WSUS 3.0 and SCCM 2007. This makes management a lot easier for me. SP2 is definitely a must for SCCM 2007.
After SQL Server 2005 has been setup, ASP.NET 2.0 needs to be allowed in IIS
If SQL Server 2005 will be on a different machine, you need to set the Service Principal Name (SPN) as well. This is discussed in detail in this Microsoft KB article
- MMC 3.0
This will be required by both WSUS 3.0 and SCCM 2007. MMC 3.0 requires .NET Framework 2.0 which was already installed because of SQL Server 2005
- BITS 2.5
This is a new download available since June 26, 2007. It’s a required component for SCCM 2007 and Windows Live OneCare (which I don’t really need). There are a lot of versions for this but the one I installed is the one for Windows Server 2003. We are definitely going to need the Windows XP version as well for client management
- WSUS 3.0
Since I will be doing patch management with SCCM 2007, I definitely need WSUS 3.0. WSUS 3.0 is required to setup a Software Update Point. This is required for every primary site server that is managing software updates. SCCM 2007 is now tightly integrated with WSUS 3.0 for patch management. WSUS 3.0 requires MMC 3.0 and .NET Framework 2.0 which has already taken cared of
- Run extadsch.exe
Similar to what you do in SMS 2003, you need to extend your Active Directory schema. You definitely need schema admins permission on your AD to do this
- Give the SCCM 2007 machine Full Control permissions on the System container in your Active Diectory
This procedure will allow your SCCM 2007 machine to create the Systems management container and its necessary objects. Since by default, the System container is not shown, you have to enable the Advance Options in your Active Directory Users and Computers
- Install System Center Configuration Manager 2007
Once you reach the system checker portion of the installation, it will give you some information on whether or not you can proceed with the installation. This was my hint that BITS Extensions for IIS was not installed
- Configure your Site Boundaries
In order for your clients to be able to find your management point with the help of Active Directory(and vice versa), you have to define your Site Boundary. Under Boundaries, create a new boundary. You can specify whether your boundary type will be an Active Directory site, an IP subnet, an IP Address Range or an IPv6 prefix. If you select an Active Directory site, you can browse thru your AD sites and read the information from there, taking advantage of your existing AD configuration.
- Configure the Discovery Method
If you will be using Active Directory as your discovery method, you need to configure this as well. Under the Discover Methods, modify the proerties of the Active Directory System Discovery. Make sure to enable Active Directory System Discovery. You can also modify the Polling Schedule but for the purpose of testing, you can check the Run discovery as soon as possible checkbox so you can see later on when you start deploying your clients whether or not it is working.
It took me a couple of days to finish my installation as I still had to configure my WSUS 3.0 to download the patches I need. September security patches from Microsoft will be the next in the queue
I was restoring a SQL Server instance on a different server for DR purposes – including system databases. What I have overlooked was the fact that restoring the msdb database would mean keeping the existing settings of the old instance into the new one. While I was trying to delete the database maintenance plans and the jobs, I kept getting an MSX-related error which prevented me from deleting the jobs. I looked at the jobs by running the sp_help_job system stored procedure and found out that the originating_server column happens to be the name of my old SQL Server instance. This was the primary reason why I could not delete the jobs either from Enterprise Manager or running the sp_delete_job system stored procedure.
To workaround that issue, I simply modified the originating_server column of the sysjobs table to the name of the current instance. After that, I was able to delete the database maintenance plans and the jobs. Now, my server is ready for DR. Log shipping configuration is the next thing to do.