ConfigMgr 2007 and Forefront Endpoint Protection 2010

Let’s start this post with a simple question. What’s the reason why the new version of Microsoft’s Forefront Endpoint Protection (FEP) 2010 is so kewl? Well, it’s the same reason why I’m blogging about it, it’s because it fully integrates with ConfigMgr 2007! In this post I will go through the installation and the integration of FEP 2010 with ConfigMgr 2007 in three parts.

(PART 1) Integration with ConfigMgr 2007 – How to install

FEP01_WelcomeFor the installation I will go through a Basic topology installation and its prerequisites (the installation has to be performed on a Central/ Primary Site server).

  1. (Optional) Install Windows Installer 3.1.
  2. (Optional) Install .NET Framework 3.5 SP1.
  3. (Optional) Install ConfigMGr Hotfix KB2271736.
  4. Run the serversetup.exe of the DVD and the Microsoft Forefront Endpoint Protection 2010 Server Setup wizard opens.
  5. On the Welcome page, type your name, the name of your organization, and click Next.
  6. On the Microsoft Software License Terms page, select the I accept the software license terms check box, and click Next.
  7. On the Installation Options page, select Basic topology, and click Next.
  8. On the Reporting Configuration page, verify the URL of your reporting server and the name of a user account that is used, type the password for the specified user account, and click Next.
  9. On the Updates and Customer Experience Options page, only select Join the Customer Experience Improvement Program, and click Next.
  10. On the Microsoft SpyNet Policy Configuration page, select Join Microsoft SpyNet, click Advanced SpyNet membership, and click Next.
  11. On the Installation Location page, specify the folder for installation, and click Next.
  12. On the Prerequisites Verification page, click Next.
  13. On the Setup Summary page, click Install.
  14. On the Installation page, click Next.
  15. On the Installation Complete page, click Finish.

(PART 2) Integration with ConfigMgr 2007 – How does it look

After the successful installation of FEP 2010, it’s time to take a closer look at how it’s integrated with ConfigMgr 2007. For this I will create a list with all the changes/ add-ons to the ConfigMgr Console that are created during the installation of FEP.

  • FEPActionsFEP Operations are added to right-click menu, and Actions pane for computer objects
  • FEP Collections are added to Site Database > Computer Management > Collections
    • FEPCollectionsDefinitions Status
      • Older Than 1 Week
      • Up to 3 Days
      • Up to 7 Days
      • Up to Date
    • Deployment Status
      • Deployment Failed
      • Deployment Succeeded
        • Deployed Desktops
        • Deployed Servers
      • Locally Removed
      • Not Targeted
      • Out of Date
    • Operations
    • Policy Distribution Status
      • Distribution Failed
      • Distribution Pending
      • Policy Distributed
    • Protection Status
      • Healthy
      • Not Reporting
      • Protection Service Off
    • Security Status
      • Full Scan Required
      • Infected
      • Recent Malware Activity
      • Restart Required
  • FEPPackagesFEP Packages are added to Site Database > Computer Management > Software Distribution > Packages
    • Microsoft Corporation FEP – Deployment 1.0
    • Microsoft Corporation FEP – Operations 1.0
    • Microsoft Corporation FEP – Policies 1.0
  • FEPAdvertismentsFEP Advertisements are added to Site Database > Computer Management > Software Distribution > Advertisements
    • FEP Operations
    • FEP Policies
      • Assign FEP policy Default Desktop Policy
      • Assign FEP policy Default Server Policy
  • FEPDCMFEP Configuration Baselines are added to Site Database > Computer Management > Desired Configuration Management > Configuration Baselines
    • FEP – High-Security Desktop
    • FEP – Laptop
    • FEP – Performance-Optimized Desktop
    • FEP – Standard Desktop
    • FEP Monitoring – Antimalware Status
    • FEP Monitoring – Definitions and Health Status
    • FEP Monitoring – Malware Activity
    • FEP Monitoring – Malware Detections
  • FEPConsoleFEP Console extensions are added to Site Database > Computer Management > Forefront Endpoint Protection
    • Policies
    • Alerts
      • Malware Detection Alerts
      • Malware Outbreak Alert
      • Repeated Malware Detection Alerts
      • Multiple Malware Detection Alerts
    • Reports

(PART 3) Integration with ConfigMgr 2007 – How does it work

Now we know how FEP is installed and what it all creates during the installation, let’s take a look at how it all works together. This part is not about all the possibly different settings, but about how/ when it gets called in ConfigMgr 2007.

FEPClientClient Deployment
For the deployment of the FEP client, the Microsoft Corporation FEP – Deployment 1.0 –package can be used. This package contains a script that also  will make sure that any of the following previously installed antimalware clients will be uninstalled:

  • Symantec Endpoint Protection version 11
  • Symantec Corporate Edition version 10
  • McAfee VirusScan Enterprise version 8.5 and version 8.7 and its agent
  • Forefront Client Security version 1 and the Operations Manager agent
  • TrendMicro OfficeScan version 8 and version 10

FEPPolicyClient Policies
For the policy deployment to the FEP client, the Microsoft Corporation FEP – Policies 1.0 –package will be used. By default the already existing advertisement of Assign FEP policy Default Desktop Policy and Assign FEP policy Default Server Policy are used for this. This package contains a script that will make sure that policy changes, that are made through the console (and saved in XML), get updated on the clients. For this the Deployed Desktops and Deployed Servers –collections are used.

Client Operations
For the execution of the FEP client actions, the Microsoft Corporation FEP – Operations 1.0 –package will be used. This action can be performed via the right-click menu, and the Actions pane for computer objects. After this the computer object gets populated in the Operations –collection and the script (of this package) gets assigned to the collection.

FEPDashboardClient Health
For the client health the FEP Dashboard (see picture) can be used. This dashboard shows an overview of Deployment Status, Policy Distribution Status, Definition Status, Protection Status, Security Status and Forefront Endpoint Protection Baselines. The statuses are based on the memberships of the FEP * Status –collections. So indirect the membership –queries of these collections make sure what the dashboard shows.

Client Updates
For the client updates it’s still possible to use an Auto-Approval rule for Definitions Updates in WSUS.

More information about FEP 2010: http://technet.microsoft.com/en-us/library/gg412482.aspx

ConfigMgr 2007 and removing a Computer from a Collection by script

I have to admit that it’s just really easy/ handy to create scripts to make life a bit easier. This also counts for this scenario… A customer wants to prevent, at all costs, that a computer can’t get re-imaged “by accident”. It already happened a few times that somebody by accident did a Clear Last PXE Advertisement on a Computer, or even on a Collection.

An easy solution for this scenario is to run a script at the end of a Task Sequence that will remove the Computer directly from the Collection. This makes sure that a computer can’t get re-imaged, as it’s not a member of the collection anymore. For this you can use the script from this post.

RemCompfrCollThe usage of this script is cscript <ScriptName>.vbs /CollectionID:[CollectionID] /ComputerName:[ComputerName]. Keep in mind that it needs to be run with an account that has enough rights in ConfigMgr. See also this picture for an example.

Option Explicit

DIM objSWbemLocator, objSWbemServices, ProviderLocation, Location, sSiteServerName
DIM sComputerName, sCollectionID, objCollection, colRuleSet, Rule, objArguments

‘=============================
‘ Check arguments
‘=============================
Set objArguments = Wscript.Arguments
If WScript.Arguments.Count = 2 Then
   sCollectionID = objArguments.Named.Item(“CollectionID”)
   sComputername = objArguments.Named.Item(“ComputerName”)
Else
   Wscript.Echo “Usage: RemoveComputerFromCollection.vbs /CollectionID:[CollectionID] /ComputerName:[ComputerName]”
   Wscript.Quit(0)
End If

‘=============================
‘ MAIN Script
‘=============================
sSiteServerName=”<SiteServerName>”
ConnectToSMSProvider(sSiteServerName)

Set objCollection = objSWbemServices.Get(“SMS_Collection='” & sCollectionID & “‘”) 
colRuleSet = objCollection.CollectionRules
For Each Rule In colRuleSet
    If Rule.Path_.Class = “SMS_CollectionRuleDirect” Then 
        If LCase(Trim(Rule.RuleName)) = LCase(Trim(sComputerName)) Then 
            objCollection.DeleteMembershipRule Rule
            Wscript.Echo “Succesfully removed ” & sComputerName & ” from collection: ” & sCollectionID
        End If
    End If
Next

‘=============================
‘ Sub Routine to Connect to the SMS Provider
‘=============================
Sub ConnectToSMSProvider(SiteServerName)
   Set objSWbemLocator = CreateObject(“WbemScripting.SWbemLocator”)
   Set objSWbemServices = objSWbemLocator.ConnectServer(SiteServerName, “root\sms”)
   Set ProviderLocation = objSWbemServices.InstancesOf(“SMS_ProviderLocation”)
   For Each Location In ProviderLocation
      If Location.ProviderForLocalSite = True Then
         Set objSWbemServices = objSWbemLocator.ConnectServer(Location.Machine, “root\sms\site_” + Location.SiteCode)
      End If
   Next
End Sub

WScript.Quit(0)

ConfigMgr 2007 and changing the Package Source Directory by script

Sometimes there is a good reason to get out of your comfort zone. One of those reasons is moving the Source Directory of all packages to a different server/ share. This means there has to come a script to change the Source Directory of all packages, as it is not a job that you want to do manually, and scripting is not really my thing… But as it cost me some time to create something nice of it, I will share it so everyone can “enjoy it”.

I created three subroutines, one for connecting to the SMS Provider, one for changing the Package Source Path and one for change the Content Source Path. The Package Source Path counts for all the different types of packages and the Content Source Path only counts for Drivers. The only thing that needs to be adjusted is the old and the new location of the Package Source Directory. This script needs to be run from the Site Server.

Dim objSWbemServices

Set FSO = CreateObject (“Scripting.FileSystemObject”)
Set logFile = FSO.CreateTextFile (“PkgSourcePathLOG.csv”)

sOldServerShare = “<SERVER>\<SHARE>”
sNewServerShare = “<SERVER>\<SHARE>”
 
ConnectToSMSProvider()
ChangePkgSourcePath(“SMS_Package”)
ChangePkgSourcePath(“SMS_SoftwareUpdatesPackage”)
ChangePkgSourcePath(“SMS_ImagePackage”)
ChangePkgSourcePath(“SMS_OperatingSystemInstallPackage”)
ChangePkgSourcePath(“SMS_DriverPackage”)
ChangeContentSourcePath(“SMS_Driver”)

‘==================================
‘ Sub Routine to Connect to the SMS Provider
‘==================================
Sub ConnectToSMSProvider()
   Set objSWbemLocator = CreateObject(“WbemScripting.SWbemLocator”)
   Set objSWbemServices = objSWbemLocator.ConnectServer(“.”, “root\sms”)
   Set ProviderLocation = objSWbemServices.InstancesOf(“SMS_ProviderLocation”)
   For Each Location In ProviderLocation
      If Location.ProviderForLocalSite = True Then
         Set objSWbemServices = objSWbemLocator.ConnectServer(Location.Machine, “root\sms\site_” + Location.SiteCode)
      End If
   Next
End Sub

‘==================================
‘ Sub Routine to Change the Package Source Path
‘==================================
Sub ChangePkgSourcePath(strClass)
   Set colSWbemObjectSet = objSWbemServices.execQuery(“SELECT * FROM ” & strClass)
   For Each objSWbemObject In colSWbemObjectSet
      sOldPkgSourcePath = objSWbemObject.PkgSourcePath
      sNewPkgSourcePath = Replace(sOldPkgSourcePath, sOldServerShare, sNewServerShare)
      logFile.Write “Setting Package Source Path for ” & objSWbemObject.Name & ” from ” & sOldPkgSourcePath & ” to ” & sNewPkgSourcePath
      objSWbemObject.PkgSourcePath = sNewPkgSourcePath
      objSWbemObject.put_
   Next
End Sub

‘==================================
‘Sub Routine to Change the ContentSource of Drivers
‘==================================
Sub ChangeContentSourcePath(strClass)
   Set colSWbemObjectSet = objSWbemServices.execQuery(“SELECT * FROM ” & strClass)
   For Each objSWbemObject In colSWbemObjectSet
      sOldPathString = objSWbemObject.ContentSourcePath
      sNewPathString = Replace(sOldPathString, sOldServerShare, sNewServerShare)
      logFile.Write “Setting Content Source Path for ” & objSWbemObject.LocalizedDisplayName & ” from ” & sOldPathString & ” to ” & sNewPathString
      objSWbemObject.ContentSourcePath = sNewPathString
      objSWbemObject.put_
   Next
End Sub

Keep attention to the fact that changing the Source Directory will make the Distribution Point re-process the packages. This is the part that virtual application packages don’t like. They will generate lots of errors in the distrmgr.log and to fix it I had to touch them all and re-select the XML –file from the original project directory.

Installing and enabling Remote Server Administration Tools with ConfigMgr 2007

It took me a while to figure out something that is actually very simple and logical… I couldn’t get the different parts of the Remote Server Administration Tools (RSAT) enabled by command-line on Windows 7 x64… On Windows 7 x86 it’s pretty straight forward, as it can be done with the default DISM commands. But on Windows 7 x64 it is kind of hard to get it to use the correct version of DISM.

ConfigMgrClientThis is all because the ConfigMgr client is 32-bit application and whenever a 32-bit application wants to access %windir%\System32, it will be redirected to %windir%\SysWOW64. I tried everything, even specifying the whole path to the DISM executable, but it all didn’t matter… Until I finally figured out that there is just something called SysNative. WOW64 recognizes SysNative as a special alias used to indicate that the file system should not redirect the access. As it was kind of hard to find this information I will post my solution here to install RSAT and enable some features. This is the batch-file I ended up:

REM ======================================================
REM SET DISM Directory based on OS Architecture
REM SET RSAT Version based on OS Architecture
REM ======================================================

IF EXIST %WINDIR%\SysNative\dism.exe (
    set DISM=%WINDIR%\SysNative\dism.exe
    set RSAT=amd64fre_GRMRSATX_MSU
) ELSE (
    set DISM=%WINDIR%\System32\dism.exe
    set RSAT=x86fre_GRMRSAT_MSU
)

REM ======================================================
REM RUN WUSA to install RSAT
REM ======================================================
   
wusa.exe %~dp0%RSAT%.msu /quiet

REM ======================================================
REM RUN DISM to enable features
REM ======================================================

%DISM% /online /enable-feature /featurename:RemoteServerAdministrationTools
/featurename:RemoteServerAdministrationTools-Roles
/featurename:RemoteServerAdministrationTools-Roles-HyperV /quiet

REM ======================================================
REM EXIT Errorlevel
REM ======================================================

EXIT /b %errorlevel%

The first part of the batch-file set the variables based on the architecture and the second part will do the actual installing and enabling (in the example it will enable the Hyper-V manager). To conclude this story, follow the next five steps to install and enable Remote Server Administration Tools with ConfigMgr 2007:

  1. Download the full installer(s) of Remote Server Administration Tools (amd64fre_GRMRSATX_MSU.msu and/ or x86fre_GRMRSAT_MSU.msu) here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en.
  2. Copy the code above and create a batch-file.
  3. Create a new Package in ConfigMgr 2007 (Site Database > Computer Management > Software Distribution > Packages) and point the Data Source to the location where the installer(s) and the batch-file are.
  4. Create a new Program with the newly created package and use as command-line the name of the, just created, batch file.
  5. Create a new Advertisement of the newly created program and it is all ready to install and enable!

More information about File System Redirector: http://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx

Some often forgotten extras delivered with ConfigMgr 2007 R2/R3

I noticed lately that some extras, which are delivered/ copied with ConfigMgr 2007 R2/R3, are often forgotten to be used. So in this short post I will give them in a little time in the spotlights.

  • Virtual Application Package Tools – The Virtual Application Package Tools are available in ConfigMgr 2007 R2 to help you manage virtual application packages in your ConfigMgr 2007 environment. The following tools are included:
    • ManageVAppPackage.vbs – This script is used to update an existing virtual application package or to import a new virtual application.
    • SetRetensionRules.vbs – This script is used to configure the retention policy for virtual application packages,.
    • AppVirtMgmtClient.sms – This Package Definition File is used to create a package to install the App-V Client.
    • AppVirtMgmtSequencer.sms – This Package Definition File is used to create a package to install the App-V Sequencer.
      TechNet Article: http://technet.microsoft.com/en-us/library/cc161873.aspx
  • Forefront Client Security Configuration Pack Baseline – The Forefront Client Security Configuration Pack Baseline is a Desired Configuration Management Pack and is used to monitor the Client Security agent on clients managed by ConfigMgr 2007 R2 Sites.
    TechNet Article: http://technet.microsoft.com/en-us/library/cc161958.aspx
  • Configuration Manager 2007 Client Status Reporting – The Client Status Reporting in ConfigMgr 2007 R2 is used to provide up-to-date information on the status of client computers in a ConfigMgr 2007 hierarchy.
    TechNet Article: http://technet.microsoft.com/en-us/library/cc161956.aspx
  • Power Management Report Pack – The Power Management Report Pack in ConfigMgr 2007 R3 includes several reports and can be used to help you analyze power consumption and computer power settings in your organization.
    TechNet Article: http://technet.microsoft.com/en-us/library/ff977098.aspx
  • Power Viewer – The Power Viewer is a tool included with ConfigMgr 2007 R3 and can be used to view power management-related information on ConfigMgr 2007 client computers.
    TechNet Article: http://technet.microsoft.com/en-us/library/ff977077.aspx

Besides these handy reports and tools there are also some standard extras on the full installation source. Some ADM Templates for configuring client settings and some scripts for reconfiguring request ports.

Configuration Manager 2007 R3 has arrived!

The System Center team is very excited to announce the release of System Center Configuration Manager 2007 R3.  This release is a significant accomplishment for the engineering team for a lot of reasons.  Not only does ConfigMgr R3 drive new scenario support to existing world class capabilities, it raises core functionality to new levels of industry leading status.

………………

For the full article take a look here:

http://blogs.technet.com/b/systemcenter/archive/2010/10/14/configuration-manager-2007-r3-is-here.aspx

ConfigMgr 2007, Updating a Windows 7 Image with the latest Software Updates – A less conventional, but very effective way

Inspired by a previous post about the option to Schedule Updates for an already existing Operating System Image in ConfigMgr vNext, I created a little batch-file to do something similar without the GUI of ConfigMgr vNext. Of course, I do know that the ‘best practice’ for ConfigMgr 2007 is to just run another Build and Capture Task Sequence, but in some cases this can come in handy. One thing is for sure, this updates a Windows 7 Image within fifteen minutes.

Background Story

Now lets start with a little background story, to explain why in some situations there might be the need for this batch-file. Every month there are new Software Updates released by Microsoft. During the Software Updates Deployment the, for the organization needed, updates get selected and downloaded to the Software Update Package. In other words, the, for the organization needed, updates are already downloaded and available. To update the existing image with the newest updates, the ‘best practice’ is to deploy the newest updates and run another Build and Capture Task Sequence. Sometimes, especially at smaller companies, this is considered as a lot of extra work/ effort and because of that, it is often forgotten. Even though an up-to-date Windows 7 Image deploys a lot faster then a Windows 7 Image that still has to install a lot of Software Updates. So to help out the people that are just to busy (you can actually fill in anything you want, I just like to think that they are to busy), I created this batch-file that will do everything.PckgSrcLctn

Input Locations

Well… after this all being said, lets take a look at the two most important inputs that we need for this batch-file:

  1. The current setup of the batch-file assumes that there is a  Software Updates Package for all Windows 7 (x86 and x64) updates. The Package source of this package is used as input for this batch-file. This location can be found in the Properties of the Software Updates Package (see the first picture) in the ConfigMgr Console. By doing this, it is not needed to re-download the Software Updates, it’s only needed to gather the Software Updates together from all the subdirectories.
  2. Another important input for the batch-file is the location of the Windows 7 Image, which has to be updated. For this the Image path can be used, which can be found in the Properties of the Operating System Image (see the second picture) in the ConfigMgr Console. Don’t forget that it is still needed to update the Distribution Point(s) after the batch-file has run!

Batch-fileImgPth

As we know now a little background story and we know where the most important parts of the input comes from, lets take a look at the batch-file that will make it happen.

REM =========================================
REM ARGUMENT -1- TempPartition = %1
REM ARGUMENT -2- UpdatesPackageSource = %2
REM ARGUMENT -3- Architecture = %3
REM ARGUMENT -4- WimFileAndLocation = %4
REM ARGUMENT -5- FromDate MM-DD-YYYY = %5
REM ===================================================

REM ===================================================
REM Make (temporary) directories for updates and mounting
REM ===================================================

MD %1\TEMP\Mount
MD %1\TEMP\Updates

REM ======================================================
REM Copy new updates of %3 -architecture and of > %5 -date to temporary directory
REM ======================================================

FOR /R %2 %%P IN (*%3.cab) DO (
XCOPY "%%P" %1\TEMP\Updates /H /C /Y /D:%5
)

REM ======================================================
REM Mount image, add updates, commit and unmount
REM ======================================================

DISM /Mount-Wim /WimFile:%4 /Index:1 /MountDir:%1\TEMP\Mount /LogPath:%1\DISM.Log
DISM /Image:%1\TEMP\Mount /Add-Package /PackagePath:%1\TEMP\Updates /LogPath:%1\DISM.log
DISM /Unmount-Wim /MountDir:%1\TEMP\Mount /Commit /LogPath:%1\DISM.log

REM ======================================================
REM Remove (temporary) directories again
REM ======================================================

RD %1\TEMP /S /Q

The biggest part will explain itself, with or without the comments, but it also shows here that I am using five variables. This is to make it easier adjustable for different Windows 7 Images, Package source location, architectures and dates. These variables are used in the following way:

  1. %1 – Presents the volume that can be used to store the temporary folders.
  2. %2 – Presents the full location of the Software Updates Package source.
  3. %3 – Presents the architecture of the Operating System.
  4. %4 – Presents the full location of the Operating System Image, including the name of it.
  5. %5 – Presents the date of the oldest Software Updates that have to be added (Format: MM-DD-YYYY).

Now lets end this post with how to run this batch-file:
[NameOfBatchFile].BAT [DriveLetter:] [SoftwareUpdatesPackageSourceLocation] [Architecture] [WIMLocation\WIMName] [DateLatestNeededUpdates]

ConfigMgr 2007, PXE Service Point and DHCP Options

As I’m getting some questions lately about the DHCP Options in combination with PXE Service Points (PSP), I decided to devote this post to those possibilities. When talking about a PSP and DHCP Options, there are three often used options:

  • 060 = client Identifier (PXEClient)
  • 066 = boot server host name
  • 067 = boot file name

Now lets start with saying: “It shouldn’t be necessary to make manual additions to the DHCP Options on the DHCP Server”. Now I can already hear the questions pop-up, what about a combined server of DHCP and WDS/PSP, what about crossing over subnets and vlans, etc., etc.. These are all good and justified questions, but not necessary.

DHCP Option 060

In case there is a combined server of DHCP and WDS/PSP, then there is the need for a DHCP Option 060 (client identifier), but as I stated “no manual additions”. This all gets done by the installation of the PSP. Just follow these steps and no manual addition is needed:

  1. Install WDS and do not configure it.
  2. (Optional) Restart the server.
  3. Install PXE Service Point (takes care of creating DHCP Option 060).
  4. Change the REGVALUE UseDHCPPorts to 0. This value can be found in: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSPXE
  5. Run the command: WDSUTIL /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes
  6. (Optional) Restart the server.

DHCP Option 066 and 067

In case there is traffic crossing over subnets and vlans then then there is the need for a DHCP Option 066 (boot server host name) and 067 (boot file name). Okay, I do admit that it’s easy to configure DHCP Options in this case, but also not necessary… Its mentioned multiple times, even by Microsoft (http://support.microsoft.com/kb/926172), that DHCP Options are not as reliable as IP Helpers. So i would always advise to use IP Helpers instead of DHCP Options.

Now to conclude my story I would like to say that: “It shouldn’t be necessary to make manual additions to the DHCP Options on the DHCP Server”.

More information about Planning for PXE Initiated Operating System Deployment: http://technet.microsoft.com/en-us/library/bb680753.aspx

ConfigMgr 2007, Client Push Installation – The server-side story

Sometimes its good to freshen-up some “hidden” knowledge. Its somewhere in your head, but it just needs to be freshened. One of these things is the Client Push Installation. In this post I will try to tell the story of the server side.

Prerequisites for Client Push Installation

To be able to do a successful Client Push Installation, the following prerequisites need to be met:

  • There must be a Client Push Installation –account defined in the Accounts tab of the Client Push Installation Properties.
  • The Client Push Installation –account must be a member of the local Administrators group on the targeted computer.
  • The targeted computer must have been discovered a ConfigMgr discovery method.
  • The targeted computer must have an ADMIN$ share.
  • The targeted computer must be able to contact a management point in order to download supporting files. See for more information my previous post about the ports used by a Client Push Installation.

Install the ConfigMgr Client using Client Push Installation

There a two methods of installing a ConfigMgr Client using Client Push Installation and I will described them both here, automatic and manual installation.

Method 1: Automatic Client Push InstallationClientPushInstallProp

  1. Open the Configuration Manager Console and browse to System Center Configuration Manager > Site Database > Site Management > <YourSiteName> > Site Settings > Client Installation Methods.
  2. Select Client Push Installation and click in the Actions pane Properties to open the Client Push Installation Properties.
  3. On the General tab select Enable Client Push Installation to Assigned Resources.
  4. (Prerequisite) On the Accounts tab specify an account to use when connecting to the targeted computer to install the client software.
  5. (Optional) On the Client tab specify any additional installation properties and click Ok.

Important (!): The specified installation properties, on the Client tab, must be for the client.msi. Also, the specified installation properties are published to the Active Directory if the schema is extended. These properties are used by client installations where the ccmsetup is run with no installation properties.

Method 2: Manual Client Push Installationimage

  1. (Prerequisite) On the Accounts tab (of the Client Push Installation Properties) specify an account to use when connecting to the targeted computer to install the client software.
  2. (Optional) On the Client tab (of the Client Push Installation Properties) specify any additional installation properties.
  3. Navigate to System Center Configuration Manager > Site Database > Computer Management > Collections.
  4. Select the collection or computer in a collection you want to push the client to. Right-click the computer or collection and then select Install Client to launch the Client Push Installation wizard and click Next.
  5. On the Installation options page, specify the client installation options that should be used and click Next.
  6. Review the installation settings, and click Finish to close the wizard

The Client Push Installation server-side –process

  • After a Client Push Installation is initiated a Client Configuration Request (CCR) –record gets created for each targeted computer. These records are created in <InstallationDirectory>\inboxes\ccr.box.
  • As soon as the CCR –record gets processed it will be moved to <InstallationDirectory>\inboxes\ccr.box\inproc. 
  • Based on the information of the CCR –record there will be a connection to the ADMIN$ share on the  targeted computer.
  • After the connection with the ADMIN$ was successful there will be a connection with the registry (IPC$), of the targeted computer, to gather information. 
  • Now the file copying will start. The MobileClient.tcf (from <InstallationDirectory>\bin\I386), the ccmsetup.exe and any needed updates (from <InstallationDirectory>\Client) are downloaded to ADMIN$\ccmsetup on the targeted computer.
  • After this the last thing that happens from the server-side is the verification whether the ccmsetup service is started successfully or not. When the ccmsetup –service is started successfully the CCR –record will be deleted and when the ccmsetup –service is not started (or created) successfully the CCR –record will be moved to <InstallationDirectory>\inboxes\ccrretry.box. Standard behavior is that those records get evaluated every hour.

Extra: If a installation fails and you want to prevent it from retrying every hour, just delete the corresponding CCR –record from the ccrretry.box.

ConfigMgr vNext: It just gets easier and easier.

Its about time that I write my first post about ConfigMgr vNext BETA and well I really have to say that it just gets easier and easier compared to ConfigMgr 2007. The only thing I have to get used to is that everything is in a different location.

Capture User Files and Setting Offline (WinPE) with Hard-Links

HardLinkOnOffvNextAs I have been busy a lot with capturing user files offline on my blog, lets start about how easy that becomes in ConfigMgr vNext. I still remember making BAT-files to run the ScanState –commands, in ConfigMgr vNext its just selecting the checkboxes Capture locally using links instead of copying files and Capture in off-line mode (WinPE only). After this the Capture User Files and Settings –step will run with the command C:\_SMSTaskSequence\Packages\P010000A\amd64\scanstate.exe C:\_SMSTaskSequence\UserState /o /localonly /efs:skip /all /v:5
/offlineWinDir:C:\WINDOWS /c /hardlink
/nocompress /l:X:\WINDOWS\TEMP\SMSTSLog\scanstate.log
/progress:X:\WINDOWS\TEMP\SMSTSLog\scanstateprogress.log
/i:C:\_SMSTaskSequence\Packages\P010000A\amd64\miguser.xml /i:C:\_SMSTaskSequence\Packages\P010000A\amd64\migapp.xml.

Even the variable OSDStateStorePath gets set to %_SMSTSUserStatePath% automatically by selecting Save user settings locally during the Create Task Seqeunce Wizard.

Schedule Updates on a Operating System Image

ImageProp Another cowl feature I ran into, with creating the Operating System Image for the Task Sequence, is the option to Schedule Updates for an already created Operating System Image. By doing this ConfigMgr will insert the selected updates into the Operating System Image. No more problems with installing Software Updates during the Build and Capture –proces, can it get easier then this?

After this it is also possible to see the which Software Updates exist in the Operating System Image (see picture). Now you will always be able to see how up-to-date your reference image is!

Of course there are lots and lots of more cowl feature, like the Software Center, the Online Software Catalog, the Automatic Grouping Rules for Software Updates, the Client Agent Settings, etc, etc, etc… But, at my defence, these are all to big to be covered in one post.