Does your Windows 7 Hang at the Welcome Screen for a long time after logon? Potential Fix Here

I’ve had a major issue on my personal machine for sometime now where on logon my machine would hang for minutes (15-30 minutes in some cases) before getting to the desktop. When resuming from sleep, this wasn’t an issue, however on cold boots or restarts this was a big issue.

The fix was http://support.microsoft.com/kb/2526870 which fixes a group policy deadlock condition.

Location of SMSTS.log when using Configuration Manager Operating System Deployment

For those using OSD to image, the smsts.log is a valuable log file to help in troubleshooting installation issues of your Windows images. The smsts.log file, however, moves around depending on what phase of the installation you are in. Below is a list of the location depending on where you are in the installation process:

  • Windows PE before HDD format: x:\windows\temp\smstslog\smsts.log
  • Windows PE after HDD format: x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Full version Windows before SCCM agent installed: c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Full version Windows after SCCM agent installed: c:\windows\system32\ccm\logs\Smstslog\smsts.log
  • Full version Windows (x64) after SCCM agent installed: c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
  • After Task Sequence has finished running: c:\windows\system32\ccm\logs\smsts.log
  • After Task Sequence has finished running (x64): c:\windows\sysWOW64\ccm\logs\smsts.log

System Center Configuration Manager 2012 Beta 2 VHD Now Available

We have posted the ConfigMgr 2012 Beta 2 VHD. You can download the files here.

With this release you can also test out the Forefront Endpoint Protection 2012 Beta which integrates with ConfigMgr 2012. Take a look at the link at the bottom of this post for more information on how to get the FEP 2012 beta.

System requirements

Supported Operating Systems: Windows Server 2008 R2 Enterprise

Hyper-V is required to run this virtual machine. In addition to Hyper-V, you will need a 64-bit system with hardware-assisted virtualization enabled, as well as data execution prevention (DEP).

Hyper-V can be run from one of the following environments:
– Windows Server 2008 SP2
– Windows Server 2008 R2
– Windows Server 2008 R2 SP1

Prerequisites, installation steps, OS recommendations and known issues of Hyper-V can be found here.

Instructions

1. Download all parts of the VM archive
2. Run the self-extracting RAR archive.
3. When prompted, accept the EULA. The VM will now be extracted.
4. Import the VM into Hyper-V

By default, this VM comes configured without a virtual NIC assigned. If you do not have a virtual NIC already defined in Hyper-V Manager, you will need to configure one. This is required in order to activate your 180 day trial period. You will have 10 days to activate.

Also, if you want to add more memory beyond the defaulted 4GB, do so before you launch the VM (Note: You can add a virtual NIC while the VM is running, but you cannot alter the memory)

Specific details on how to add this image to the Hyper-V library can be found in the README file included in this VM package.

If you have any questions, please contact vhdinfo@microsoft.com.

Additional information

Forefront Endpoint Protection 2012 Beta can also be evaluated using this VHD. FEP 2012 Beta software is available for download here. More information on FEP 2012 and its integration with System Center Configuration Manager 2012 is provided on the technet documentation site.

How to Install Secondary Sites in System Center Configuration Manager 2012

In prior versions of ConfigMgr, you had the ability to install a secondary site in multiple ways. The method that I always chose to install a secondary was to copy the installation bits down to the server and install via setup.exe. The other method was using the ConfigMgr admin console which would copy the content from the primary server down to the secondary server and do the installation for you.

In ConfigMgr 2012, there no longer is an ability to manually copy the bits to the server you would like to make a secondary and run setup.exe. The only way to install a secondary is via the Admin console. You can, however, still use source files that are located via a UNC share on another server (either at the secondary site itself or in some software repository).

Active Directory Forest Account

Now before we actually get into the installation of the secondary, we should talk about publishing sites to active directory and a new feature that lets us specify an Active directory forest account.

An active directory forest account is a new feature that connects to an active directory forest and does two things:

  1. Discovers AD Sites and IP subnets to automatically create boundaries
  2. Publishes site information to the AD forest

The second item is what I want to focus on.

In the past, when setting up a ConfigMgr site server, the computer object needed full rights to the System\System Management container in AD. With the AD Forest account, this is no longer the case as you can create a service account and give it full rights to the System\System Management container.

In order to specify your Active Directory Forest Account, do the following:

  1. Open the ConfigMgr Admin Console
  2. Click on the Administration node
  3. Drill into Overview, Site Hierarchy, Active Directory Forests
  4. In the pane on the right, right click your forest (in my case richbal.local) and select Properties
  5. At the bottom of the Forest Properties window specify your Active Directory Forest Account

It’s not mandatory that an account be specified, as you can still use computer accounts to publish to the System Management container, however I think using a service account will make things a lot easier with admins not having to remember to populate a group with computer objects and wondering why Hierarchy Manager is giving an error after every site being built.

Installing the Secondary

Now that the AD Forest account has been created, we can install the secondary and be sure that it will be able to publish to AD.

Prerequisites

On the computer you plan to use for a secondary server, make sure to configure the following

  • The user account to install the secondary server must be a local administrator on the secondary server
  • The computer account of the primary server must be a local administrator on the secondary server
  • Remote Differential Compression (RDC) must be enabled
  • BITS must be enabled

 

To install a secondary site:

  1. Open the ConfigMgr Admin Console
  2. Click on the Administration Node
  3. Expand Site Operations
  4. Click on Sites

You should see all of the sites in your environment (and if you’re reading this post, you likely have only one primary which should be listed in the right pane). In the ribbon you should see a number of actions, one of which is Create Secondary Site.

Click on Create Secondary site to begin the wizard

Click Next at the welcome screen

Fill in the appropriate information. If you would like to have the default secondary settings, click Summary, otherwise click Next.

Note: Something to consider, if you are installing CM12 in the same domain as a CM07 site, you will need to have different site codes in order to prevent issues with publishing to AD (amongst other things).

If you would like to prestage the content on the secondary, you can do that and specify the source files location using a UNC path. You can also use a UNC path that might be a software repository location in your environment. In my case, I’m going to let ConfigMgr copy the installation source files over the network from the parent site.

New to ConfigMgr 2012 is the need for secondary site servers requiring a SQL database. By default, we’ll use a local copy of SQL Server Express (and do the install for you). However you have the option of using a full install of SQL server on the secondary server itself, or using an existing SQL server remote to the secondary. In my case I will allow ConfigMgr to configure a local copy of SQL Server Express on my secondary server.

Another new feature in the secondary site installation is the ability to create the addresses during installation for both the address going FROM the secondary TO the primary, and the address going FROM the primary TO the secondary. In ConfigMgr 2007 you had to create the address going from the primary down to the secondary which wasn’t exactly something a new ConfigMgr administrator would remember.

One thing you’ll see a lot in ConfigMgr 2012 is this concept of groups. In the past we had DP groups (and in 2012 we have enhanced those), but now in 2012 we have this concept of Boundary Groups.

I won’t detail boundary groups in this topic since there’s enough for a separate topic on that, but suffice it to say that boundaries can now be used hierarchy wide and are no longer to be used at the site specified. In order for a boundary to actually be used, a boundary group needs to be defined and applied to a site system (either distribution point or state migration point). In my case for this post, I have not created a boundary group for this site.

Review the summary and click next and at the completion screen click close.

In your ConfigMgr console you should now see something similar to the above picture. In the past, you wouldn’t have any installation status of the secondary site if installing from the administrator console. Notice at the top on the ribbon there is an option for Show Install Status? If we click on that we see the following:

Wow! We actually have the ability via the console to see exactly what’s going on during a secondary site installation!

But what about that failure on the first line? Why did we fail? If we dig a little into the above window, we can see that we failed in a few places:

  1. Configuration Manager Setup requires that the logged on user possess administrative rights on the site server computer – Well, this can’t be true, since we do have domain admin rights and those rights are on the server
  2. Short File Name (8.3 support) – Setup could not determine if 8.3 support is enabled, or couldn’t contact the server – this is possible
  3. Firewall is on and ports 1433 and 4022 are not open – this can prevent sites in different domains from communicating

So these are the three main failures, but the installation status doesn’t give me all the information I want. So where would I go to look at that?

The first place I would look is in the hman.log (located at <installdir>\logs\hman.log).

And here we found an issue where the prereq check didn’t pass, secondary site installation will be cancelled. Please check configMgrPrereq.log for results.

The ConfigMgrPrereq.log is located at c:\ConfigMgrPrereq.log. Opening that log gives us a little more information:

Here’s our message about not having user administrative rights, which is not true.

The next error talks about short file name support not being verified. This error is actually the following:

Short File Name (8.3) Support (Site system); Error; Setup either could not verify that short file name (8.3) support is enabled on the computer specified for site system installation or the server could not be contacted to determine short file name support information. No further prerequisite checking rules can be evaluated on the specified system. Setup cannot continue.

The next error talks about the Firewall exception for SQL server. Since we’re not in a cross domain situation, we can probably throw this one out. But we also have one last error to look at that wasn’t listed in the status:

Failure to insert DRWCfg registry key, values, and subkeys; error = 3.

So in total, we have four errors. What do we do to fix this?

We should either open the firewall ports for SQL (or disable the firewall if it’s not needed). We should also give local administrator rights to the primary server computer object. So once that’s done, we need to reinstall the secondary.

Unfortunately, to reinstall the secondary, we have to go through the wizard again. So if you run into issues installing a secondary site, delete the failed to install entry you have for the secondary you just installed and re-run the secondary install (you may have to refresh your view to see the Failed to Install state).

When you delete a secondary site, you are presented with the Delete Secondary Site Wizard:

The difference between uninstall and delete is simply that when you uninstall, it actually removes the bits and information about the site from the secondary site server itself as well as the hierarchy and AD. The delete secondary site option removes the information about the site from the hierarchy and AD, but doesn’t remove anything on the secondary server itself. In my case, I want to delete the secondary site since we didn’t communicate out to the secondary server and install anything.

Click next (or summary) to get through the rest of the wizard. Once finished, you may need to refresh your console view in order to see the secondary removed. Once it’s removed from the console, re-create the secondary site.

If the c:\Configmgrprereq.log passes the checks, you can watch the <ConfigMgr Install Dir>\Logs\Hman.log to see the secondary install package creation process (this may take a few minutes). You can then skip ahead to watching the sender.log which will ultimately send the package to the secondary site.

So for your perquisites for a secondary server, make sure to configure the following (as referenced above) to prevent any of the above issues from happening.

  • The user account to install the secondary server must be a local administrator on the secondary server
  • The computer account of the primary server must be a local administrator on the secondary server
  • Remote Differential Compression (RDC) must be enabled
  • BITS must be enabled

 

 

 

 

 

 

How to Install a System Center Configuration Manager 2012 Primary Site (Beta 2)

System Center Configuration Manager (ConfigMgr) 2012 primary site installation isn’t that much different than in ConfigMgr 2007, however there are some differences. The aim for this post is to show you the basics of primary site installation and what to look for post installation.

Prerequisites

ConfigMgr 2012 has nearly the same prerequisites as ConfigMgr 2007, with the difference being that in 2012 we no longer require WebDAV to be present for MPs or DPs. This makes the installation on 2008 and 2008 R2 servers much easier.

  • Requires both .net 3.5 and .net 4.0
  • SQL 2008 SP1 with CU 10 or Greater (SQL 2008 R2 is NOT supported in the beta, but will be at release, and likely at RC)
  • WSUS 3.0 SP2
  • Remote Differential Compression
  • BITS Installed/Enabled
  • Computer account of the site server needs to have Full control rights to the System Management container and all child objects in active directory (this is unchanged from previous versions of SMS/SCCM)

Site Installation

Install Screenshots

Assess server readiness does not currently function in beta 2 (at least it didn’t for me).

I chose to download the latest ConfigMgr updates, however during the install it will ask you to download them, or provide a path where the latest updates have been downloaded.

Get the latest Configuration Manager updates downloads the following prerequisites:

  • Microsoft Remote Differential Compression Library (32 and 64 bit versions)
  • Windows Update Agent 3.0 (32 and 64 bit versions)
  • WMI Redistributable Components version 1.0
  • Silverlight Runtime
  • .NET Framework Client Profile 4.0 RTM
  • SQL Server 2008 Express
  • MSXML 6.0 Service Pack 1
  • SQL Server 2008 Native Client
  • SQL Server 2008 System CLR Types
  • SQL Server 2008 Management Objects
  • SQL Server 2008 Replication Management Objects

Click Install after the updates are downloaded.

Click Next

Click Next

Accept and click Next

Either download or specify the location of the updates and click next

Note: In beta 2 there is currently a bug when specifying a folder with spaces to either download, or use a previous location that you may have downloaded the updates to earlier. Make sure to use a folder with no spaces in the path.

Click next

Fill in the items and click next.

Since I don’t have an existing hierarchy, this will be a standalone site for now. Click Next.

By default the SQL server, the database, and the SQL replication snapshot folder will be filled in for you. I choose to have SQL installed on my E:\ drive, and will also have the replication snapshot location there. Click Next.

At this point, if you don’t have SQL 2008 SP1 with CU10 or greater installed, you will get an error. You MUST have SQL 2008 SP1 (no R2).

Click Next unless your provider location is another server

Native mode has changed since SCCM 2007 (it’s not even called Native Mode anymore). We now are allowed to use either HTTP or HTTPs (or a hybrid of both methods). In my test environment, I’ll be using HTTP communication since I do not have PKI certificates.

Click Next

By default a Management Point and Distribution Point can be installed. You also have the ability to select the protocol, either HTTP or HTTPS.

Click Next

Click Next at the Customer Experience Improvement Program

Click Next at the summary screen

I purposely configured my server with the bare minimum configuration to see what prerequisites the prerequisite check would find. These are the four that showed up on my Windows 2008 R2 SP1 server that I only installed .net 3.5, .net 4, SQL 2008 SP1 and SQL 2008 SP1 CU13.

Fix any issues, click run check, and click next

Click Begin

As the progress is being monitored, you can click the view log button to see what the installer is doing. The log is located at C:\ConfigMgrSetup.log

Pro tip: If you go to the directory where you extracted the beta, open the Tools folder, and you will find a new version of trace32.exe. This is actually called System Center Trace now and is a 64 bit version of the application (it should probably be renamed to trace64 or something else).

And if all goes well, you should see the above screen.

Click close and the console should open up.

Using SCCM Distribution Points for Forefront Endpoint Protection 2010 Definition Updates

THIS METHOD HAS BEEN DEPRECIATED AS OF FOREFRONT ENDPOINT PROTECTION UPDATE ROLLUP 1. PLEASE SEE FOREFRONT ENDPOINT PROTECTION 2010 UPDATE ROLLUP 1 USING YOUR DISTRIBUTION POINTS FOR FEP DEFINITIONS WITH THE SOFTWARE UPDATE AUTOMATION TOOL FOR THE NEW METHOD.

 

 

 

 

As you are probably aware by now, Forefront Endpoint Protection 2010 (FEP 2010) integrates with SCCM to provide you with one console to manage your entire environment, leveraging your SCCM infrastructure to help deploy anti-malware protection.

One of the problems we have with SCCM is the ability to leverage the Software Updates capabilities automatically. For each software update you wish to deploy, you have to add it to a deployment package as well as a deployment. This is fine for monthly security patches, however this process isn’t very good when dealing with anti-virus updates since most vendors release updates multiple times a day.

FEP doesn’t help matters much with this issue, and a lot of customers have had issues with not being able to leverage their SCCM distribution points. FEP gives you three methods to deploy definitions:

  1. WSUS
  2. Microsoft Update
  3. UNC File Share

I won’t go deep into the pros and cons of each, but suffice it to say that none of these will leverage your distribution points (unless you create UNC shares and point your clients to your DPs, which is possible with different policies, but somewhat of a pain).

Leveraging your DPs

So how can we leverage our DPs if the above three options don’t allow us to do so?

The way we accomplish this is rather simple:

  1. Have a script to download the definition files
  2. Create software distribution packages that point to the location where our definitions have been downloaded and update those on an 8 hour schedule (since FEP updates are released 3 times a day)
  3. Create collections of machines with out of date definitions (both 64bit and 32 bit) – I’ll explain this a bit more in a second
  4. Create a recurring advertisement to install the definitions

But before we do all that, we have to understand how the definition process in FEP works.

Forefront Endpoint Protection Definition Files

FEP has 4 definition files

  1. Full definition file (Base ~60MB as of this writing)
  2. Binary Delta Definition (1-15MB)
  3. Delta Definition (1-15MB)
  4. Network Inspection Service Definition File (only used on clients where NIS has been enabled)

For each of these files, there is an x86 and x64 file, so 8 total files available.

Your full definition file is generally between 40-70MB in size and will normally be installed after a new FEP Client install.

The binary delta definition file is generally 1-15MB in size and is used if your client is more than a month behind in its definition updates.

The delta definition file is generally 1-15MB in size (usually smaller than the binary delta definition file) and it installed typically on a daily basis (released 3 times a day).

More information about the definition files can be found at: http://support.microsoft.com/kb/977939

One thing to keep in mind about the definition files is that these files can be downloaded manually EXCEPT for the Binary Delta Definition files. I’m still trying to track down a link to download these files, and when I do, I’ll make sure to post an update here.

Putting This All Together

So now that we know the files we’re dealing with, let’s put this together.

First thing we need to do is setup a process to download the definition files automatically.

Create the following directories (I’m using the C: drive in this example, but you can use any of those, just make sure to modify the script I reference below)

  • “C:\FEPDefinitions\Updates\delta\amd64”
  • “C:\FEPDefinitions\Updates\delta\x86”
  • “C:\FEPDefinitions\Updates\full\amd64”
  • “C:\FEPDefinitions\Updates\full\x86”
  • “C:\FEPDefinitions\Updates\NIS\amd64”
  • “C:\FEPDefinitions\Updates\NIS\x86”
  • “C:\FEPDefinitions\script”
  1. Download the following script and save it under “C:\FEPDefinitions\script”
  2. Edit the script to download the definitions if you don’t plan on using the C:\FEPDefinitions locations

Create the Scheduled Task

  1. Go to Start – Programs – Administrative Tools – Task Scheduler
  2. In the Actions Pane on the right select Create Task…
  3. For each of the tabs, use the following screen shots (conditions and history don’t need to be modified)
    General

    Triggers

    Actions

    Settings
  4. Once the task is setup, go ahead and run it and verify that the definitions are downloading to the locations you have specified. All of the folders you created before should have definition files now.

Creating the SCCM Packages

So now that we have the content downloaded, we need SCCM to be made aware of it and download it on a schedule to our DPs. In total you will need to create 6 packages. (x86 and x64 packages for the Full and Delta definitions as well as x86 and x64 packages for the full NIS definition if you plan to use NIS). I will walk you through creating one package, you should repeat the process for the other 5 packages.

  1. In the SCCM Packages node in the SCCM Console, right click on the Packages node and  select New and then select Folder. Name it FEP Definitions.
  2. Right click the FEP Definitions folder and select New and then select Package
  3. In the new package wizard, input appropriate information for this package and click next
  4. In the data source screen, check the This package contains source files box
  5. For source directory, type in \\servername\sharename\FEPDefinitions\Updates\delta\amd64
  6. Leave Always obtain files from source directory checked
  7. Check the box to Update distribution points on a schedule
  8. Click the Schedule button
  9. For the custom schedule, select a custom interval to recur every 8 hours
    Note:
    Make this 8 hour schedule to be 15-30 minutes after the download is scheduled to run. This will allow the schedule task some time to download the definitions before SCCM tries to create a new package.
  10. Check Enable binary differential replication
  11. Click Finish

When all is said and done, your General and Data Source tabs of your package should look like this.

General


Data Source

Repeat the above steps for the other 5 packages (3 packages if you aren’t planning on pushing out NIS definitions).

Once the packages are all created, make sure to send each package to your distribution points.

Create the Programs for each Package

I’ll walk you through creating a program for the x64 delta definition (which is the same package I walked you through above).

  1. Drill to Software Distribution – Packages – FEP Definitions – Microsoft Corporation FEP Delta Definitions x64 – Programs
  2. Right click on Programs and select New – Program
  3. In the New Program Wizard, type in a name for the program
  4. For the command line, click browse, and select the mpam-d.exe file
  5. Add a -q as a command line switch, so your command line should look like mpam-d.exe -q
  6. Click Next
  7. Click Next at the Requirements screen
  8. In the Program can run drop down box, select Weather or not a user is logged on
  9. Click Next
  10. In the Advanced screen, select Suppress program notifications
  11. Click next all the way to the end of the wizard

Repeat the above steps for each package you made in the previous section.

Creating Your Collections

So now that we have created the packages to update every 8 hours (since the FEP definitions are released 3 times a day…and as a side note, no, I don’t know the time of day they are released, I have a pending question on that, so for now, just do it 3 times a day), now we need to target an advertisement to a collection, however we have an issue.

We basically have 3 definition types, we have a full update which is about 65MB in size (as of this writing) and we have a delta update which is about 3MB in size (as of this writing) as well as a NIS full definition update which is also about 3MB in size. We know that the 65MB update is for new clients as well as clients that have definition updates older than 2 months. We know that the delta definitions are for machines that have been updated with a definition within the last month. We also know there is a binary delta definition file (which we don’t have the ability to download, or at least I’m unaware of the location of the BDD file) for clients that have definitions that are at least a month old, but aren’t older than two months.

So based on all this information, we know that we don’t want our clients to download 65MB if it’s unnecessary. We only want those who are older than a month to download the full definition update (because we don’t have the BDD file we have to use this criteria, if we had the BDD file, we’d have a collection of machines with definitions older than a month but not older than two months).

In order to find the machines to target with these updates, we need to make some DCM rules. These DCM rules will allow us to populate collections dynamically based on the dates of their definition files.

Creating the Desired Configuration Management Configuration Items

What we’ll be doing here is creating 3 different configuration items

  1. Custom FEP Monitoring – Check if NIS is enabled
  2. Custom FEP Monitoring – Definitions Greater than a Month Old
  3. Custom FEP Monitoring – Definitions Up to a Month Old

Custom FEP Monitoring – Check if NIS is enabled

  1. Navigate to Desired Configuration Management – Configuration Items
  2. Right Click on Configuration Items
  3. Select New – General Configuration Item
  4. In the name field type Custom FEP Monitoring – Check if NIS is Enabled
  5. Click Next
  6. In the Objects screen, click Next
  7. In the Settings screen, click New – WQL Query
  8. For Display Name type in NisEnabled = True
  9. For Description type in Checks to see if NIS is enabled on a machine
  10. For Namespace type in Root\Microsoft\SecurityClient
  11. For Class type in AntimalwareHealthStatus
  12. For Property type in NisEnabled
  13. Click the Validation tab
  14. For Data Type select String
  15. Click New
  16. In the Configure Validation screen, for Name type in NisEnabled = True
  17. For Operator select Equals
  18. For Value select True
  19. For Severity select Information – no Windows event message
  20. Click OK
  21. Click Next all the way through the rest of the wizard

Custom FEP Monitoring – Definitions Greater than a Month Old

  1. Navigate to Desired Configuration Management – Configuration Items
  2. Right Click on Configuration Items
  3. Select New – General Configuration Item
  4. In the name field type Custom FEP Monitoring – Definitions Greater than a Month Old
  5. Click Next
  6. In the Objects screen, click Next
  7. In the Settings screen, click New – WQL Query
  8. For Display Name type in Definitions Greater than a month old
  9. For Namespace type in Root\Microsoft\SecurityClient
  10. For Class type in AntimalwareHealthStatus
  11. For Property type in AntivirusSignatureAge
  12. Click the Validation tab
  13. For Data Type select Integer
  14. Click New
  15. In the Configure Validation screen, for Name type in Antimalware Definitions Age Rule
  16. For Operator select Greater than or equal to
  17. For value type in 30
  18. For severity select Information – no windows event message
  19. Click OK
  20. Click Next all the way through the rest of the wizard

Custom FEP Monitoring – Definitions Up to a Month Old

  1. Navigate to Desired Configuration Management – Configuration Items
  2. Right Click on Configuration Items
  3. Select New – General Configuration Item
  4. In the name field type Custom FEP Monitoring – Definitions Up to a Month Old
  5. Click Next
  6. In the Objects screen, click Next
  7. In the Settings screen, click New – WQL Query
  8. For Display Name type in Definitions Up to a month old
  9. For Namespace type in Root\Microsoft\SecurityClient
  10. For Class type in AntimalwareHealthStatus
  11. For Property type in AntivirusSignatureAge
  12. Click the Validation tab
  13. For Data Type select Integer
  14. Click New
  15. In the Configure Validation screen, for Name type in Antimalware Definitions Age Rule
  16. For Operator select Less than
  17. For value type in 30
  18. For severity select Information – no windows event message
  19. Click OK
  20. Click Next all the way through the rest of the wizard

Creating the Desired Configuration Management Baseline

So now that we have created the 3 CIs, we need to create a baseline to target your machines that have succeeded in deployment of the FEP client. This baseline will allow the 3 Configuration Items to evaluate. Once these CIs have evaluated, the steps below for creating the collections will allow the collections to populate with machines that are out of date with their definitions.

  1. Navigate to Desired Configuration Management – Configuration Baselines
  2. Right Click on Configuration Baselines
  3. Select New Configuration Baseline
  4. In the name field type Custom FEP Monitoring – Definition Status
  5. Click Next
  6. In the Rules box, click the applications and general blue link. This will open a dialog box to choose Configuration Items
  7. In the Choose Configuration Items dialog box, select Custom FEP Monitoring – Check if NIS is Enabled, Custom FEP Monitoring – Definitions Greater than a Month Old, and Custom FEP Monitoring – Definitions Up to a Month Old
  8. Click OK
  9. Click Next
  10. Click Next
  11. Click Close
Now that the baseline is created, we need to assign it to one or more collections. I actually assign mine to the Out of Date and Deployment Succeeded collections, however you probably can get away with just assigning it to Deployment Succeeded. To assign the baseline to a collection:
  1. Navigate to Desired Configuration Management – Configuration Baselines
  2. Right click on Custom FEP Monitoring – Definition Status
  3. Click Assign to Collection
  4. In the Assign Configuration Baseline Wizard dialog box, click Next
  5. Click Browse
  6. In the Browse Collection dialog, navigate to FEP Collections\Deployment Status\Deployment Succeeded
  7. Click OK
  8. Click Next
  9. For the baseline evaluation schedule, you can stick with the default of 7 days, or change this to be more frequent if you desire
  10. Click Next
  11. Click Next
  12. Click Close
Now once the baseline evaluates, the collections you create in the steps below should begin to populate with machines.

Creating the Collections

So now that we have the DCM Configuration Items created, we can now create our collections leveraging the compliance of the CI and the CI Unique_ID. There are a few ways to do this, however I’ll show you the way I did it. There’s no right or wrong way, just your own way :)

For NIS Enabled Machines

  1. Navigate to Desired Configuration Management – Configuration Items
  2. Right click on Custom FEP Monitoring – Check if NIS is Enabled
  3. Select Create New Collection – Compliant Systems
  4. In the New Collection Wizard click Next
  5. In the Membership Rules screen double click on the Compliant Systems rule
  6. In the Query Rule Properties window, select Edit Query Statement
  7. In the Custom FEP Monitoring… window select Show Query Language
  8. Copy the entire query statement
  9. In the console, navigate to Computer Management – Collections – FEP Collections
  10. Right Click on FEP Collections and select New – Collection
  11. Call this collection NIS Enabled x64
  12. Click Next
  13. In the Membership Rules screen click the yellow cylinder icon to make a query based collection
  14. In the Query Rule Properties name field, type in NIS Enabled X64
  15. Click on Edit Query Statement
  16. Click on Show Query Language
  17. Paste in the query from step 8 (should be on your clip board)
  18. Click Show Query Design
  19. Click the Criteria tab
  20. There should be three lines of text in your criteria, the Configuration Item Compliance State.CIUnique_ID is equal to… as well as the compliance state is equal to one
  21. Click the Yellow Starburst icon to create a new criterion
  22. Click the Select… button
  23. For Attribute class select Computer System
  24. For Attribute select System Type
  25. Click OK
  26. For Value type in x64-based PC
  27. Click OK
  28. Select Dynamically Add New Resources
  29. Click Schedule…
  30. Set the custom schedule to update every 7 hours (this way the collections update slightly more frequently than the advertisements run since the advertisements will run every 8 hours)
  31. Click OK
  32. Click Next all the way to the end

You’ll want to repeat the above steps another 5 times for each of your different platform types (x86 or x64) as well as the different types of definitions. In the end, you should have six collections that look like the following:

Advertisements

The last thing you’ll want to do is create your advertisements to target each of the six collections. Below you can find the screen shots of what your advertisements should look like. If you’d like, I can write up the wizard steps by step items. The key step here is to make sure that the advertisements are set to always re-run.

General

Schedule

Distribution Points

In total, you should have six advertisements. 2 for the full definitions, 2 for the deltas, and 2 for the NIS definitions.

And with that, you should now be able to have your clients download their FEP definitions from their distribution points. There’s a lot of overhead in setting this all up, but once done, you shouldn’t really have to ever touch the process.

I understand that setting things up this way is a pain. In SCCM 2012 this should get better with the auto approval of updates, but in SCCM 2007 land, there really isn’t a better way without making your DPs Software Update Points and having WSUS installed on all of them (not ideal).

If you have any questions, please let me know. Also, if things don’t look right or I missed something, again, let me know. Thanks!

Ports Required to Join a Windows Domain – Managing Windows Machines in a DMZ with SCCM

For those looking for the ports you need open, this is what I use for a Windows 7 and Windows 2008 R2 DC.

LDAP TCP-in – 389
LDAP UDP in – 389
LDAP for Global Catalog TCP in – 3268
NetBIOS name Resolution UDP in – 138
SAM/LSA TCP in – 445
SAM/LSA UDP in – 445
Secure LDAP TCP in –  636
Secure LDAP for Global Catalog TCP in – 3269
W32Time NTP UDP in – 123
RPC – RPC Dynamic
RPC Endpoint Mapper
DNS – TCP and UDP 53
Kerberos V5 UDP in – 88
Netbios Datagram UDP in – 137

Now for the long story (note that the below solution is conceptual and hasn’t been tested in a lab yet. This is just me getting things written down. I’ll update more after we put this in place) –

When managing machines that are behind a firewall, you’ll need to open ports on the firewall to get them joined to a domain. I have an interesting situation coming up next week where we need to manage machines that are in my customer’s DMZ. In the current customer’s environment, the machines in their DMZ are workgroup machines that aren’t joined to a domain.

From an SCCM Perspective, we can manage workgroup machines. However we still need the ports opened through the firewall to manage these machines. In some cases, network administrators don’t want all of their DMZ machines to go through the firewall that separates the DMZ from the internal network. We haven’t determined if that’s a route we want to take, but I personally feel that the more machines you have that can route through the firewall, the more you increase your attack vector.

My proposed solution would be to build up a secondary SCCM server in the DMZ that can only communicate through the firewall. All of the other machines in the DMZ would communicate through that server. That server doesn’t even HAVE to be a secondary site, we could just build one box with an MP and DP (or whatever other site roles you need). The secondary will just allow us to throttle bandwidth if needed.

Below is a diagram that we use for Internet Based Client management, but for managing machines in the DMZ, the process would be the same.

Network Diagram for Internet-Based Servers - Scenario 3 with No SQL Server Replica

So in our case, since there will be less than one hundred machines in the DMZ that need to be managed, we’ll probably put all site roles on one box. We’ll then need to open the ports I referenced above to allow the server to join the domain (note that all site system roles MUST be apart of a domain. They don’t have to be apart of the same domain as the site server, but they do need to be part of a domain.). Once the server is joined to the domain, we’ll need to open either port 80 or port 443 (for HTTPS) outbound to allow for the Software Update Point to communicate through the firewall. The diagram says HTTPS, but we can use HTTP since we’ll be in a mixed mode environment. For native mode environments you’d need to utilize HTTPS. We’ll also need SMB 445 outbound open to allow the site server to communicate with the other site roles in the perimeter network. We’ll also need to create an inbound rule for SQL on port 1433 for the management point to communicate with the SQL DB.

Once we’ve done all that, we’ll need to setup the appropriate rights to allow for site system installation on our server.

Client Configuration (thanks to Chris Stauffer for these tips)

In our scenario, we will be able to map to the MP’s client share to install ccmsetup.exe. We can use the ccmsetup.exe /MP:servername /logon SMSSITECODE=XYZ. We’ll likely also need to make some adjustments to the LMHosts and Hosts file.

Note that these tips should work if you have the firewall rules enabled for your clients to communicate through the firewall which would be port 80 or any custom port you’ve allowed SCCM to use.

LMHOSTS file:

Add the SMS information to a LMHOSTS file, which you can copy to each client. Use the following as a guide (WS03DC01 is the SMS server name):

192.168.1.61 ws03dc01                        #PRE
192.168.1.61 “SMS_SLP            \0x1A” #PRE
192.168.1.61 “SMS_MP              \0x1A” #PRE
192.168.1.61 “SMS_NLB             \0x1A” #PRE
# “12345678901234567890”
(note that there are 20 characters between the quote marks on each line, and the last line is just to help with spacing – it is not needed)

HOSTS file:

Add the SMS information to a HOSTS file, which you can copy to each client. Use the following as a guide (WS03DC01 is the SMS server name):

192.168.1.61 ws03dc01.domain.lcl ws03dc01

Summary

Build a server in the DMZ
Open the following inbound ports on the firewall to allow the server in DMZ to join the domain

LDAP TCP-in – 389
LDAP UDP in – 389
LDAP for Global Catalog TCP in – 3268
NetBIOS name Resolution UDP in – 138
SAM/LSA TCP in – 445
SAM/LSA UDP in – 445
Secure LDAP TCP in –  636
Secure LDAP for Global Catalog TCP in – 3269
W32Time NTP UDP in – 123
RPC – RPC Dynamic
RPC Endpoint Mapper
DNS – TCP and UDP 53
Kerberos V5 UDP in – 88
Netbios Datagram UDP in – 137

Open the following outbound ports on the firewall to allow SMB and HTTP traffic

SMB TCP/UDP – 445
HTTP TCP – 80

Open the following inbound port on the firewall to allow SQL Traffic from the MP

SQL TCP – 1433

Give rights for the site server on the intranet to the site system server in the DMZ so the site systems can install on the server.

Setup Site Roles (DP, MP, SUP)

Setup a test client and make changes to LMHOSTS and HOSTS file (if needed, not sure if necessary yet).

Install SCCM client with ccmsetup.exe /MP:servername /logon SMSSITECODE=XYZ

Some may say to use an FSP. I don’t know that it’s necessary. These client installs will be done manually, and i’d rather look at the client logs.

We’ll see how well this works this week. I’ll post an update by end of week.

System Center Configuration Manager R3 Released!

Today Microsoft released SCCM 2007 R3! Instead of going into a long blog post about all the exciting new features R3 has, I’d like to refer to an EXCELLENT run down of all the features by a co-worker of mine, Steve Rachui. If you run SCCM, R3 is definitely a worthwhile update that’s painless to implement into your existing environment.

Check out Steve’s post here.

Download the evaluation copy here.

Read the official announcement here.

SCCM: Collection Query to Find Machines Discovered via AD System Discovery in the last day without latest SCCM Client

In the final days I have with my current employer, I’ve been doing some client cleanup. As you may know, Active Directory System Discovery can make a mess out of your SCCM environment if AD isn’t kept clean. We have a lot of records in our DB that just don’t have the SCCM Client for a variety of reasons (not enough disk space, WMI is broken, etc).

The good thing about AD System Discovery though is that for each record it finds in AD, it’ll look to DNS to see if there’s a corresponding DNS record. If there is, it’ll create a DDR for that machine. So if you have a lot of junk in AD, and DNS scavenging is set to a reasonable amount of time, you should be seeing machines in your SCCM hierarchy that are actually on your corporate network.

So what I set out to do was look for all the machines that have reported back an AD System Discovery record within the last day (technically, the query below is referencing 23 hours) that doesn’t have the latest version of the SCCM client (or the client version is null). Here’s the query.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where ((DATEDIFF(hh, SMS_R_SYSTEM.AgentTime, getdate()) < 23) and AgentName = “SMS_AD_SYSTEM_DISCOVERY_AGENT”) and (SMS_R_System.ClientVersion < “4.00.6487.2000” or SMS_R_System.ClientVersion is null)

This gives me all the machines that I need to look into to fix. These are machines I wasn’t able to hit using Client Push installations, or at least I never got a successful client installation for them.