Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new or have changed for client deployment since Configuration Manager 2007:

• Clients are no longer configured for mixed mode or native mode, but instead use HTTPS together with public key infrastructure (PKI) certificates or HTTP together with self-signed certificates. Clients use HTTPS or HTTP according to the configuration of the site system roles that the clients connect to and whether they have a valid PKI certificate that performs client authentication.
  
  On the Configuration Manager client, in Properties, on the General tab, review the Client certificate value to determine the current client communication method. This value displays PKI certificate when the client communicates with a management point over HTTPS, and Self-signed when the client communicates with a management point over HTTP. Just as the client property value for the Connection type updates, depending on the current network status of the client, so the Client certificate client property value updates, depending on with which management point the client communicates.
  
  
• Because System Center 2012 Configuration Manager does not use mixed mode and native mode, the client installation property /native: [<native mode option>] is no longer used. Instead, use /UsePKICert to use a PKI certificate that has client authentication capability, if it is available, but fall back to an HTTP connection if no certificate is available. If /UsePKICert is not specified, the client does not attempt to communicate by using a PKI certificate, but communicates by using HTTP only. Additionally, use the new command /NoCRLCheck if you do not want a client to check the certificate revocation list (CRL) before it establishes an HTTPS communication.
  
  
• The client.msi property SMSSIGNCERT is still used but requires the exported self-signed certificate of the site server. This certificate is stored in the SMS certificate store and has the Subject name Site Server and the friendly name Site Server Signing Certificate.
  
  
• When you reassign a client from a Microsoft System Center 2012 Configuration Manager hierarchy to another System Center 2012 Configuration Manager hierarchy, the client can automatically replace the trusted root key, if the new site is published to Active Directory Domain Services and the client can access that information from a global catalog server. For this scenario in Configuration Manager 2007, you had to remove the trusted root key, manually replace the trusted root key, or uninstall and reinstall the client.
  
  
• The server locator point is no longer used for site assignment or to locate management points. This functionality is replaced by the management point. The CCMSetup Client.msi property SMSSLP remains supported, but only to specify the computer name of management points.
  
  
• You no longer install International Client Packs when you want to support different languages on the client. Instead, select the client languages that you want during Setup. Then, during the client installation, Configuration Manager automatically installs support for those languages on the client, enabling the display of information in a language that matches the user’s language preferences. If a matching language is not available, the client displays information in the default of English. For more information, see the Planning for Client Language Packs section in the Planning for Sites and Hierarchies in Configuration Manager topic.
  
  
• Decommissioned clients are no longer displayed in the Configuration Manager console, and they are automatically removed from the database by the Delete Aged Discovery Data task.
  
  
• The Client.msi property for CCMSetup, SMSDIRECTORYLOOKUP=WINSPROMISCUOUS, is no longer supported. This setting allowed the client to use Windows Internet Name Service (WINS) to find a management point without verifying the management point's self-signed certificate.
  
  
• To support the new 64-bit client, the location of the CCM folder for client-related files (such as the client cache and log files) has changed from %windir%\system32 to %windir%. If you reference the CCM folder for your own script files, update these references for the new folder location for System Center 2012 Configuration Manager clients. System Center 2012 Configuration Manager does not support the CCM folder on paths that support redirection (such as Program Files and %windir%\system32) on 64-bit operating systems.
  
  
• Automatic, site-wide client push now installs the Configuration Manager on existing computer resources if the client is not installed, and not just newly discovered computer resources.
  
  
• Client push installation starts and tracks the installation of the client by using the Configuration Manager database and no longer creates individual .CCR files. When you enable client push installation for a site, all discovered resources that are assigned to the site and that do not have a client installed are immediately added to the database, and client installation begins.
  
  
• Configuration Manager can automatically upgrade Configuration Manager 2007 and System Center 2012 Configuration Manager clients to the latest System Center 2012 Configuration Manager version when they are below a version that you specify. For more information see the How to Automatically Upgrade the Configuration Manager Client section in the topic How to Install Clients on Windows-Based Computers in Configuration Manager.
  
  

Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new or have changed for client deployment in Configuration Manager SP1:

• Configuration Manager can automatically upgrade Configuration Manager 2007 and System Center 2012 Configuration Manager clients to the version of their assigned System Center 2012 Configuration Manager site. For more information see the How to Automatically Upgrade the Configuration Manager Client for the Hierarchy section in the topic How to Install Clients on Windows-Based Computers in Configuration Manager.
  
  
• You can now specify the following CCMSetup.exe properties as installation options when you use client push:
  
  
  • /forcereboot
    
    
  • /skipprereq
    
    
  • /logon
    
    
  • /BITSPriority
    
    
  • /downloadtimeout
    
    
  • /forceinstall
    
    
• Configuration Manager SP1 clients now use Microsoft Silverlight 5 for the Application Catalog. Configuration Manager automatically installs this version of Silverlight on clients if it is not already installed, and by default, configures the Computer Agent client setting Allow Silverlight applications to run in elevated trust mode to Yes. For more information, see the Certificates for Silverlight 5 and Elevated Trust Mode Required for the Application Catalog section in the Security and Privacy for Application Management in Configuration Manager topic.
  
  
• There is a new value that is now the default for the Computer Agent client setting PowerShell execution policy: All Signed. This new value restricts the Configuration Manager client to running Windows PowerShell scripts only if they are signed by a trusted publisher, regardless of the current Windows PowerShell configuration on the client computer. For more information, see the Computer Agent section in the About Client Settings in Configuration Manager topic.
  
  
• The new Computer Agent client setting, Disable deadline randomization, by default, disables the installation randomization delay for required software updates and required application deployments. For more information, see the Computer Agent section in the About Client Settings in Configuration Manager topic.
  
  
• Client notification in Configuration Manager enables some client operations to be performed as soon as possible, instead of during the usual client policy polling interval. For example, you can use the client management task Download Computer Policy to instruct computers to download policy as soon as possible. Additionally, you can initiate some actions for Endpoint Protection, such as a malware scan of a client.
  
  By default, client notification communication uses TCP port 10123, which is configurable as a site property for a primary site. You might have to configure Windows Firewall on the management point, clients, and any intervening firewalls for this new port communication. However, client notification can fall back to using the established client-to-management point communication of HTTP or HTTPS. Actions taken by client notification are displayed in the new Client Operations node in the Monitoring workspace.
  
  For more information, see How to Configure Client Communication Port Numbers in Configuration Manager and How to Manage Clients in Configuration Manager.
  
  
• You can install the Configuration Manager client on computers that run Mac OS X. You can then manage this client by using compliance settings, deploying software, and by collecting hardware inventory. For more information, see How to Install Clients on Mac Computers in Configuration Manager.
  
  
• You can install the Configuration Manager client on servers that run a supported version of Linux or UNIX. You can then manage this client by using deploying software, and by collecting hardware inventory. For more information, see How to Install Clients on Linux and UNIX Computers in Configuration Manager.
  
  

If your Windows Embedded device does not include the Configuration Manager client, you can use any of the client installation methods if the device meets the required dependencies. If the embedded device supports write filters, you must disable these filters before you install the client, and then re-enable the filters again after the client is installed and assigned to a site.

Write filters control how the operating system on the embedded device is updated when you make changes, such as when you install software. When write filters are enabled, instead of making the changes directly to the operating system, these changes are redirected to a temporary overlay. If the changes are only written to the overlay, they are lost when the embedded device shuts downs. However, if the write filters are temporarily disabled, the changes can be made permanent so that you do not have to make the changes again (or reinstall software) every time that the embedded device restarts. However, temporarily disabling and then re-enabling the write filters requires one or more restarts, so that you typically want to control when this happens by configuring maintenance windows so that restarts occur outside business hours.

When you install software on Windows Embedded devices with Configuration Manager with no service pack, you must always take additional steps to disable the write filters, install the software, and then re-enable the write filters. However, if the embedded client runs Configuration Manager SP1, you can configure options to automatically disable and re-enable the write filters when you deploy software such as applications, task sequences, software updates, and the Endpoint Protection client. The exception is for configuration baselines with configuration items that use automatic remediation. In this scenario, the remediation always occurs in the overlay so that it is available only until the device is restarted. The remediation is applied again at the next evaluation cycle, but only to the overlay, which is cleared at restart. To force Configuration Manager SP1 to commit the remediation changes, you can deploy the configuration baseline and then another software deployment that supports committing the change as soon as possible.

If the write filters are disabled, you can install software on Windows Embedded devices by using Software Center. However, if the write filters are enabled, the installation fails and Configuration Manager displays an error message that you have insufficient permissions to install the application.

Warning
Even if you do not select the Configuration Manager SP1 options to commit the changes, the changes might be committed if another software installation or change is made that commits changes. In this scenario, the original changes will be committed in addition to the new changes.

When Configuration Manager SP1 disables the write filters to make changes permanent, only users who have local administrative rights can log on and use the embedded device. During this period, low-rights users are locked out and see a message that the computer is unavailable because it is being serviced. This helps protect the device while it is in a state where changes can be permanently applied, and this servicing mode lockout behavior is another reason to configure a maintenance window for a time when users will not log on to these devices.

Configuration Manager supports the following types of write filters:

• File-Based Write Filter (FBWF). For more information, see File-Based Write Filter on MSDN.
  
  
• Enhanced Write Filter (EWF) RAM. For more information, see Enhanced Write Filter on MSDN.
  
  

Configuration Manager does not support write filter operations when the Windows Embedded device is in EWF RAM Reg mode.

Important
If you have the choice, use File-Based Write Filters with Configuration Manager SP1 for increased efficiency and higher scalability. When you have this configuration, configure the following exceptions to persist client state and inventory data between device restarts: CCMINSTALLDIR\*.sdf CCMINSTALLDIR\ServiceData HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\StateSystem

For an example scenario to deploy and manage write-filter-enabled Windows Embedded devices in Configuration Manager SP1, see Example Scenario for Deploying and Managing Configuration Manager Clients on Windows Embedded Devices.

For more information about how to build images for Windows Embedded devices and configure write filters, see your Windows Embedded documentation, or contact your OEM.

Note

When you select the applicable platforms for software deployments and configuration items, these display the Windows Embedded families rather than specific versions. Use the following list to map the specific version of Windows Embedded to the options in the list box: Embedded Operating Systems based on Windows XP (32-bit) includes the following: Windows XP Embedded Windows Embedded for Point of Service Windows Embedded Standard 2009 Windows Embedded POSReady 2009 Embedded operating systems based on Windows 7 (32-bit) includes the following: Windows Embedded Standard 7 (32-bit) Windows Embedded POSReady 7 (32-bit) Windows ThinPC Embedded operating systems based on Windows 7 (64-bit) includes the following: Windows Embedded Standard 7 (64-bit) Windows Embedded POSReady 7 (64-bit)

The following checks and remediations can be performed by client check.

Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new or have changed for client status since Configuration Manager 2007:

• Client check and client activity information is integrated into the Configuration Manager console.
  
  
• Typical client problems that are detected are automatically remediated.
  
  
• The Ping tool used by Configuration Manager 2007 R2 client status reporting is not used by System Center 2012 Configuration Manager.
  
  

Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new for mobile devices since Configuration Manager 2007:

• Enrollment for mobile devices in Configuration Manager is now natively supported by using the two new enrollment site system roles (the enrollment point and the enrollment proxy point) and a Microsoft enterprise certification authority. For more information about how to configure and enroll mobile devices in Configuration Manager, see How to Install Clients on Mobile Devices and Enroll Them by Using Configuration Manager.
  
  
• New in Configuration Manager, the Exchange Server connector lets you find and manage devices that connect to Exchange Server, on-premise or hosted, by using the Exchange ActiveSync protocol. Use this mobile device management process when you cannot install the Configuration Manager client on the mobile device. For more information, see How to Manage Mobile Devices by Using the Exchange Server Connector in Configuration Manager.
  
  
• If you have mobile devices that you managed with Configuration Manager 2007, and you cannot enroll them by using System Center 2012 Configuration Manager, you can continue to use them with System Center 2012 Configuration Manager. The installation for this mobile device client is still the same. However, whereas Configuration Manager 2007 did not require PKI certificates, System Center 2012 Configuration Manager requires PKI certificates on the mobile device and the management points and distribution points. File collection is no longer supported for these mobile device clients in Configuration Managerand, unlike the mobile devices that you can enroll with Configuration Manager or manage by using the Exchange Server connector, you cannot manage settings for these mobile devices. In addition, the mobile device management inventory extension tool (DmInvExtension.exe) is no longer supported. This functionality is replaced with the Exchange Server connector.
  
  

Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new for mobile devices in Configuration Manager SP1:

• The client settings group to configure mobile device enrollment settings is no longer named Mobile Devices and is now named Enrollment. This change and associated changes, such as the change from the client setting of Mobile device enrollment profile to Enrollment profile, reflects that the enrollment functionality is now extended to Mac computers.
  
  

  Important
  The client certificates for mobile devices and Mac computers have different requirements. Therefore, if you configure client settings enrollment for mobile devices and Mac computers, do not configure the certificate templates to use the same user accounts.

• Mobile devices that are enrolled by Configuration Manager SP1 now use the client policy polling interval setting in the Client Policy client setting group and no longer use the polling interval in the renamed Enrollment client setting group. This change lets you configure different client policy intervals for mobile devices that are enrolled by Configuration Manager, by using custom device client settings. You cannot create custom device client settings for Enrollment.
  
  
• You can enroll mobile devices that run Windows Phone 8, Windows RT, and iOS when you use the Windows Intune connector. For more information, see How to Manage Mobile Devices by Using the Windows Intune Connector in Configuration Manager.
  
  
• Users who have mobile devices that are enrolled by Windows Intune and Android devices that are managed by the Exchange Server connector can install apps from the company portal. The company portal is the Application Catalog equivalent for these mobile devices.
  
  
• The new Retire option for mobile devices in the Configuration Manager console is supported only for mobile devices that are enrolled by Windows Intune.