Capability: Desktop, Device and Server Management
On This Page
Introduction
Requirement: Automated Patch Distribution to Desktops and Laptops
Checkpoint: Automated Patch Distribution to Desktops and Laptops
Requirement: Defined Standard Images for Desktops and Laptops
Checkpoint: Defined Standard Images for Desktops and Laptops
Requirement: Centralized Management of Mobile Devices
Checkpoint: Centralized Management of Mobile Devices
Requirement: Identity Validation, Data Protection, and Data Backup of Mobile Devices
Checkpoint: Identity Validation, Data Protection, and Data Backup of Mobile Devices Checkpoint
Requirement: Consolidation of Desktop Images to Two Operating System Versions
Checkpoint: Consolidation of Desktop Images to Two Operating System Versions
Introduction
Desktop, Device and Server Management is the second Core Infrastructure Optimization capability. The following table describes the high-level challenges, applicable solutions, and benefits of moving to the Standardized level in Desktop, Device and Server Management.
Challenges |
Solutions |
Benefits |
|---|---|---|
Business Challenges Risk of unauthorized access to sensitive data on mobile devices Inability to define mobile policies by organization or unit Policies for device settings vary Lack of centralized corporate standards for managing or enforcing device policies IT Challenges No standards for hardware, operating systems, and applications Desktops are not centrally managed, resulting in increased operations and software distribution costs Inconsistent patch management leads to more security vulnerabilities IT is highly reactive, spending resources fighting unpredicted issues Inability to remotely remove data from lost or stolen devices |
Projects Deploy automated, centralized patch management solution Implement standardized lite touch, image-based deployment solution Implement a management solution for monitoring critical servers Implement a mobile device provisioning solution that includes security policy provisioning, remote wipe, and policy enforcement |
Business Benefits Mobile workers stay current with direct connectivity between corporate networks and devices Using a system management tool will reduce per-PC management costs IT Benefits Monitoring services help simplify identification issues, quickly determine the cause of the problem, and efficiently restore services to prevent potential IT problems PCs that are faster and less expensive to deploy Reduced help desk and operations costs Administrators can ensure data protection and compliance with corporate security policies, including ability to set password policies and remotely remove data from devices |
The Standardized level in the Infrastructure Optimization Model addresses the key areas of management including:
Automated Patch Distribution to Desktops and Laptops
Defined Standard Images for Desktops and Laptops
Consolidation of Desktop Images to Two Operating System Versions
Centralized Management of Mobile Devices
Identity Validation, Data Protection, and Data Backup of Mobile Devices
The Standardized level of optimization requires that your organization has procedures and tools in place to automate patch distribution, manage and consolidate standard desktop images, and centrally manage connected mobile devices.
Requirement: Automated Patch Distribution to Desktops and Laptops
Audience
You should read this section if you do not have an automated patch distribution process in place for 80 percent or more of your desktops and laptops.
Overview
IT professionals today face immense challenges in implementing an effective software update management strategy: more devices and mobile users are now accessing corporate networks; there is a consistent stream of security updates from software and hardware vendors; footprints for systems and applications are expanding; there is an almost daily identification of new security threats; and the hacking community is now much more sophisticated.
Phase 1: Assess
The Assess phase is the first major step in the patch management process. The process starts with assessment, because you will need to determine what you have in your production environment, the security threats and vulnerabilities you might face, and whether your organization is prepared to respond to a new operating system or application software update.
Ideally, assessment is an ongoing process that you should follow to ensure that you always know what computing assets you have, how you can protect them, and how you can ensure that your software distribution architecture is able to support patch management.
The key areas for ongoing assessment are:
Inventory/discover existing computing assets.
Assess security threats and vulnerabilities.
Determine the best source for information about software updates.
Software version control to maintain standard application versions.
Assess the existing software distribution infrastructure.
Assess operational effectiveness.
A number of tools, utilities, and products are available from Microsoft to help in the Assess phase of patch management. These include:
A comparison of these tools is located at the end of this section. Microsoft partners and other third parties offer additional products and tools that can be used in the Assess phase.
Phase 2: Identify
The goals for the Identify phase are to:
Discover new software updates in a reliable way.
Determine whether software updates are relevant to your production environment.
Obtain software update source files and confirm that they are safe and will install successfully.
Determine whether the software update should be considered an emergency.
Discovering a new software update starts with notification, which should be supplied either through a subscription to a reliable source that provides scanning and reporting activities, or by some other reliable notification mechanism. The following are the most commonly used notification mechanisms:
E-mail notifications: https://www.microsoft.com/technet/security/bulletin/notify.mspx.
Viewing updates in the Windows Server Update Service (WSUS) console toolbar.
SMS 2003 Inventory Tool for Microsoft Updates (ITMU): https://www.microsoft.com/technet/downloads/sms/2003/tools/msupdates.mspx.
Vulnerability scanning tools, such as MBSA, to scan for missing updates.
You can determine the applicability of a software update to your IT infrastructure using the following screening methods:
Reading security bulletins and Knowledge Base articles.
Reviewing individual software updates.
After you have obtained the update, it should be verified through the following activities:
Identifying and verifying the software update owner.
Reviewing all accompanying documentation.
Ensuring that the software update is free from viruses.
Phase 3: Evaluate and Plan
Your goal during the Evaluate and Plan phase is to make a go/no-go decision to deploy the software update, determine what resources it will take to deploy it, and test the software update in a production-like environment to confirm that it does not compromise business-critical systems and applications.
The key requirements for evaluation and planning are:
Determine the appropriate response.
Plan the release of the software update.
Build the release.
Conduct acceptance testing of the release.
To determine the appropriate response to an available update you should:
Prioritize and categorize the request.
Obtain authorization to deploy the software update.
Release planning is the process of working out how you will release the software update into the production environment. Following are the major considerations for planning the release of a new software update:
Determine what needs to be patched.
Identify the key issues and constraints.
Build the release plan.
To build the release, you must develop the scripts, tools, and procedures that administrators will use to deploy the software update into the production environment.
Testing should be carried out, regardless of whether the software update is regarded as normal or business-critical, with the following results:
After the software update installation is complete, the computer should restart and operate without incident.
The software update, if it is targeted at computers connected across slow or unreliable network connections, can be downloaded across these links, and, after this completes, the software update successfully installs.
The software update is supplied with an uninstall routine, and this can be used to successfully remove the software update.
Business-critical systems and services continue to run after the software update has been installed, and the machine has restarted, if that is a necessary step.
A best practice is to have a testing and validation infrastructure in place to test software updates before they are put into production. Guidance for building a testing and emulation environment is provided in the Windows Server System Reference Architecture Virtual Environments for Development and Test.
Microsoft Virtual Server 2005 R2 and Microsoft Virtual PC 2004 SP1 are free product downloads and can be used as part of your testing and validation infrastructure.
Phase 4: Deploy
Your goal during the Deploy phase is to successfully roll out the approved software update into your production environment so that you meet all of the requirements of any deployment service level agreements (SLAs) you have in place.
The deployment of a software update should consist of the following activities:
Deployment preparation.
Deployment of the software update to client computers.
Post-deployment review.
The production environment needs to be prepared for each new release. The steps required for preparing the software update for deployment should include the following:
Communicating the rollout schedule to the organization.
Staging updates on distribution points.
The steps required to deploy a software update in production should include the following:
Advertising the software update to client computers.
Monitoring and reporting on the progress of deployment.
Handling failed deployments.
The post-implementation review should typically be conducted within one to four weeks of a release deployment to identify improvements that should be made to the patch management process. A typical agenda for a review includes:
Ensure that the vulnerabilities are added to your vulnerability-scanning reports and security policy standards so the attack does not have an opportunity to recur.
Ensure that your build images have been updated to include the latest software updates following the deployment.
Discuss expected results compared to actual results.
Discuss the risks associated with the release.
Review your organization’s performance throughout the incident. Take this opportunity to improve your response plan and include lessons learned.
Discuss changes to your service windows.
Operations
The patch management process is an ongoing and iterative cycle. While Operations is not a patch management phase in the Infrastructure Optimization Model, it is necessary that IT operations define the frequency of patching that best suits your organization’s needs and security goals. Your organization should define a system for determining the critical nature of released patches and have a service level defined for each patch release level.
Available Tools
A number of tools and products can automate the delivery and installation of software updates. As defined in best practice patching, exercising manual control over which patches are installed to managed computers is a requirement. Allowing Automatic Updates or Microsoft Update to run unchecked does not comply with best practice patch management for organizations; however, in some cases, when dedicated IT staff is limited or users are remote and unmanaged, these technologies can be used.
The recommended options for managing software updates are Systems Management Server 2003 (SMS 2003) and Windows Server Update Services (WSUS). In addition to these options, numerous Microsoft partners and other third parties offer options to assist with patch management.
The following table lists software tools available from Microsoft to perform installation of software updates.
Feature |
|||
|---|---|---|---|
Content Types Supported |
All software updates, driver updates, service packs (SPs), and feature packs (FPs) |
Same as MU, with only critical driver updates |
All updates, SPs, & FPs, supports update & app installs for any Windows-based software |
Applicability |
Individual users |
Small- to mid-size businesses |
Enterprise customers |
Tool Coverage in Patch Process
The following table lists the primary tool-related functions in the patch process:
Product or Tool |
Hardware & Software Inventory |
Scans Target for Updates |
Identifies New Updates |
Admin Controls Installation |
Automated Deployment |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.gif "Bb821257.tick(en-us,TechNet.10).gif")
The Application Compatibility Toolkit has been included in this table because it contains functionality to determine hardware specifications and application inventory of client computers. It also includes analysis and reporting for update impacts on applications.
Ensuring that all intended software updates and service packs are installed is a key step in managing a standard configuration. Systems Management Server 2003 Desired Configuration Monitoring (DCM) has been included in this list because it will monitor compliance of a known configuration state and inform administrators if requested updates or service packs are not present on managed computers.
Patch management guidance in a future Infrastructure Optimization Implementer Resource Guide series will introduce tools and procedures for update management for servers and mobile devices.
Further Information
For more information on patch management, visit Microsoft TechNet and search on ”Patch Management" or visit the TechNet Update Management Solution Center.
To see how Microsoft addresses patch management, go to https://www.microsoft.com/technet/itshowcase/content/dtpatchmgmt.mspx.
Checkpoint: Automated Patch Distribution to Desktops and Laptops
|
Requirement |
|---|---|
|
Implemented process and tools to inventory hardware and software assets. |
|
Implemented process and tools to scan client computers for software updates. |
|
Established a process to automatically identify available patches. |
|
Established standard testing for every patch. |
|
Implemented patch distribution software. |
If you have completed the steps listed above, your organization has met the minimum requirement of the Standardized level for Automated Patch Distribution in this capability based on the Infrastructure Optimization model. We recommend that you follow the guidance of additional best practice resources for configuration monitoring and management to ensure that client patch levels are maintained to a known standard.
Go to the next Self-Assessment question.
Requirement: Defined Standard Images for Desktops and Laptops
Audience
You should read this section if you do not have a defined set of basic images for 80 percent or more of your desktops.
Overview
To succeed in deploying an operating system, organizations must use the best technology and business processes available, in addition to best practices for optimizing those technologies. By developing baselines for the computing environment, organizations have a known and fixed configuration for deployment, which lowers the cost of support, troubleshooting, and other operations. Through imaging, a standard build that includes core applications, the operating system, and any additional organization requirements can be used for workstation deployment. This document lists tools that are available and the steps you should take to automate and establish standard desktop images. Deployment of standard images will be covered in future documents.
Phase 1: Assess
Most IT implementers share a common goal: to create a corporate-standard desktop configuration that is based on a common image for each operating system version in the organization. IT implementers want to apply a common image to any computer in any region at any time, and then customize that image quickly to provide services to users.
In reality, most organizations build and maintain many images—sometimes up to 100 different images. By making technical and support compromises, making disciplined hardware purchases, and using advanced scripting techniques, some organizations have reduced the number of images they maintain to a just few. These organizations tend to have the sophisticated software-distribution infrastructures necessary to deploy applications—often before first use—and keep them updated.
In the Assess Phase it is important to inventory your workstations and determine the number of active operating systems and applications in your environment. We recommend that you use a tool to automate the inventory process, such as Systems Management Server (SMS) 2003, the Application Compatibility Toolkit, or the Windows Vista Hardware Assessment.
Phase 2: Identify
During this phase you should list any current disk-imaging technologies and standard images used by your organization and identify the imaging direction, tools, and techniques you would like to implement. Advances in desktop imaging technology should prompt consideration for updating legacy imaging tools and practices.
A number of tools are available to capture a desktop image. Imaging technology can be sector-based and usually is destructive when applied to the targeted computer, or it can be file-based and nondestructive. Using file-based image technology, you can install new images in a separate partition of deployment-targeted PCs, which allows advanced in-place migration scenarios.
Microsoft offers a free command-line tool to enable disk imaging. The imaging utility, called ImageX, uses the Microsoft Windows Imaging Format (WIM) image format. Instead of a sector-based image format, the WIM image format is file-based and nondestructive. The SMS 2003 Operating System Deployment Feature Pack also leverages ImageX technology and the WIM file format to create and deploy desktop images.
Additional tools are available in Solution Accelerator for Business Desktop Deployment (BDD) 2007 for integrating several of the steps needed to define and deploy desktop images. The Deployment Workbench, a tool contained in BDD 2007, creates distribution shares and develops disk images. Automated deployment themes in the future Implementer Resource Guides will further discuss BDD 2007 and Deployment Workbench.
Phase 3: Evaluate and Plan
During the Evaluate and Plan Phase you discuss possible approaches your organization can use to implement a standardized desktop imaging strategy. You should weigh the costs and benefits of each imaging technology and image type to develop a strategy that best suits your organization’s needs. Factors that affect the costs associated with building, maintaining, and deploying disk images are development costs, test costs, storage costs, and network costs.
As the size of image files increases, costs increase. Large images have more updating, testing, distribution, network, and storage costs associated with them. When you update even a small portion of the image, image administrators must distribute the entire file to client computers.
The three primary strategies for standard images are:
Thick images
Thin images
Hybrid images
Thick Images
Thick images contain the operating system, applications, and other corporate-standard files. The advantage of thick images is simplicity; deployment is a single step because all files are deployed at once. Also, applications are available on first run. The disadvantages are maintenance, storage, and network costs. Thick images also limit flexibility. Either all computers receive all applications whether needed or not, or many different thick images must be developed and maintained. Using thick images is a common legacy approach.
Thin Images
Thin images contain few if any applications. The advantages of thin images are many. They cost less to build, maintain, and test. Network and storage costs are lower. There is far greater flexibility. However, flexibility increases deployment and networking costs.
Hybrid Images
Hybrid images are a combination of thick and thin images. In a hybrid image, the disk image is configured to install applications on first run, giving the illusion of a thick image but installing the applications from a network source. Hybrid images have most of the advantages of thin images, yet are not as complex to develop and do not require a software distribution infrastructure. Installation times are longer, which can increase initial deployment costs.
An alternative is to start with a tested thin image and build a thick image on top of it. Testing the thick image is minimized, because the imaging process is essentially the same as a regular deployment.
Another alternative is to add a minimum number of core applications to a thin image. These applications could include antivirus software and line-of-business (LOB) applications required on all computers in the company.
Development
Recommended guidance for developing desktop images can be found in the Solution Accelerator for Business Desktop Deployment (BDD) 2007 and the Computer Imaging System Feature Team Guide. BDD 2007 discusses imaging technologies available from Microsoft and how they are used to customize, build, capture, and deploy disk images for the Windows XP SP2 and Windows Vista™ desktop operating systems.
Test Plan
Another important part of the development stage is the creation of a test plan. You need to determine all configuration scenarios in which the disk image must work. These configurations include both hardware and business processes that client machines support. A bug reporting and tracking mechanism is important to ensure that all problems that arise in testing are addressed.
Stabilization
The image and deployment process created in the Development stage must be fully tested and stabilized before deployment to the enterprise. You must diligently follow the test plan created in the Planning stage. All problems encountered should be logged and tracked with a bug reporting system. When all bugs are resolved, the final image or images can be deployed to client computers.
Phase 4: Deploy
The Deploy Phase for imaging is also discussed in the Deployment Feature Team Guide found in BDD 2007. The Standardized level of Infrastructure Optimization recommends leveraging Lite Touch Installation (LTI) of standard disk images.
BDD 2007 Lite Touch Installation requires minimal infrastructure. You can deploy target operating systems over the network by using a shared folder or locally by using removable storage, such as a CD, DVD, USB hard drive, or other device. The configuration settings for each individual computer are usually provided manually during the deployment process. See the BDD 2007 Deployment Feature Team Guide for more details.
Operations
Maintenance of the final image or images is an ongoing process. Updates to the operating system, device drivers, and applications must be analyzed for their applicability to your enterprise. Either they must be integrated into the existing image, or completely new images must be built. Then you must test and validate the final images before they can be deployed to client computers.
Available Tools
Microsoft Technologies
Product, Tool, or Utility |
Use |
|---|---|
Overall image creation, capture, and deployment methodologies and tools. Uses the Deployment Workbench to integrate many of the tools and utilities listed in this table. |
|
The Windows AIK is a set of deployment tools supporting the latest release of Windows; it includes methods, tools, and requirements for deploying Windows. |
|
Part of Windows AIK. Windows PE is a bootable tool from Microsoft that provides operating system features for installation, troubleshooting, and recovery. |
|
Windows System Image Manager (Windows SIM) |
Part of Windows AIK. Windows SIM enables creation of answer files (Unattend.xml) and network shares or modification of the files contained in a configuration set. |
Part of Windows AIK. Sysprep facilitates image creation and prepares an image for deployment to multiple client computers. |
|
Part of Windows AIK. A command-line tool that captures, modifies, and applies installation images for deployment. |
|
Windows image |
A single compressed file containing a collection of files and folders that duplicate a Windows installation on a disk volume. A Windows image is created as a WIM file and can be created using ImageX or the Systems Management Server 2003 Operating System Deployment Feature Pack. |
Other Available Products
Product |
Vendor |
|---|---|
Ghost |
|
PowerQuest |
Checkpoint: Defined Standard Images for Desktops and Laptops
|
Requirement |
|---|---|
|
Used tools to capture a standard image. |
|
Defined a strategy for standard images. |
|
Defined a standard set of disk images (OS and applications) for all hardware types. |
|
Established deployment tools for network-based or offline image installation. |
If you have completed the step listed above, your organization has met the minimum requirement of the Standardized level for Defined Standard Images for Desktops and Laptops in the Desktop, Device and Server Management capabilities of the Infrastructure Optimization Model. We recommend that you follow additional best practices for image management addressed in the Computer Imaging System Feature Team Guide found in BDD 2007.
Go to the next Self-Assessment question.
Requirement: Centralized Management of Mobile Devices
Audience
You should read this section if you do not have a centralized solution to track, manage, and upgrade your mobile devices.
Overview
Organizations worldwide are using mobile devices to accelerate business cycles, increase productivity, reduce operating costs, and extend their infrastructure. With this growing reliance on mobile devices, it is critical for administrators to understand their mobile environment, to ensure users set up secure corporate access, and to deliver new business capabilities while utilizing existing infrastructure investments.
Mobile-device management is a relatively new concept and there are limited offerings from Microsoft and its partners to supplement management tools for client and server devices.
Phase 1: Assess
In the Assess Phase, it is important to take an inventory of the mobile devices connected to your infrastructure and how people are currently using mobile devices. Organizations need to track and manage several areas of mobile-device use. To move from the Basic level to the Standardized level you need to centrally manage the following:
Discovery and tracking of mobile hardware.
Tracking, distribution, and updating of mobile software.
Data synchronization.
Proactive and reactive data security.
Defined procedures for decommissioning retired mobile devices.
This section provides information on the tools and processes that address these areas. The following sections discuss tools from Microsoft for managing mobile devices.
Phase 2: Identify
In the Identify Phase, your organization needs to develop and implement a solution for discovering the mobile devices connected to your network on an ongoing basis and determine the direction needed to manage mobile devices at a level consistent with your needs. Depending on your business and data security needs, end users may connect to your network with loosely controlled personal devices, or with managed, company-provided devices. Identification of connected devices can be performed either manually with the user volunteering information, or by using tools to discover network-connecting devices.
Phase 3: Evaluate and Plan
In the Evaluate and Plan Phase, your organization should consider which tools or technologies can be used to aid mobile device management. The primary products currently available from Microsoft are Microsoft® Exchange Server with ActiveSync®, Direct Push, Remote Wipe, and Systems Management Server (SMS) 2003 with the Device Management Feature Pack. Additional products are offered from Microsoft partners and software vendors such as Odyssey Software, Bluefire, and iAnywhere to manage mobile devices.
Exchange Server 2003 and Exchange Server 2007
Beginning with Exchange Server 2003 and continuing with Exchange Server 2007, Microsoft has introduced new capabilities for the management of Windows mobile devices. Mobile-device technologies in Exchange Server 2003 and Exchange Server 2007 are ActiveSync, Remotely Enforced Device Security Policies, and Remote Device Wipe.
Wirelessly synchronizing Microsoft® Windows Mobile®-based devices using built-in Exchange ActiveSync requires at least one server running Exchange Server in your messaging infrastructure. Note that neither Exchange 2003 nor Exchange 2007 need to be fully deployed across your organization’s entire environment to use this capability.
For information on setting up the required Exchange Server 2003 components, please see the Exchange Server 2003 deployment guide (particularly Chapter 8): https://www.microsoft.com/technet/prodtechnol/exchange/2003/library/depguide.mspx.
Also see the Exchange Server 2003 ActiveSync Architecture white paper: https://www.microsoft.com/exchange/techinfo/administration/mobiledevices.asp.
Note that earlier versions of Exchange Server do not offer built-in synchronization capabilities. You must use Exchange Server 2003 or Exchange Server 2007 for users to wirelessly synchronize their Windows Mobile-based devices.
Active Directory
For ActiveSync to work, your infrastructure must include Active Directory domain controllers. You also need to make sure that your Exchange Server 2003 servers are members of a Windows Active Directory domain.
Active Directory domain controllers must run on either Windows 2000 Server SP3 or Windows Server 2003. We recommend Windows Server 2003 for best performance.
Managing Exchange ActiveSync
By default, after you install the Client Access server role on the Exchange 2007 server, Exchange ActiveSync is enabled. End users need only configure their mobile devices to synchronize with the Exchange Server computer to use Exchange ActiveSync. Administrators can perform a variety of management tasks using Exchange ActiveSync. These include configuring Exchange ActiveSync mailbox policies and configuring authentication for increased security. You can perform some of these tasks in the Exchange Management Console and all of them in the Exchange Management Shell.
Managing Exchange ActiveSync Users
By default, if the Client Access server role is installed in a Microsoft Exchange organization that is running Exchange Server 2007, Exchange ActiveSync is enabled for all users. You can disable Exchange ActiveSync for a user or group of users and also manage various settings for your Exchange ActiveSync users.
To simplify management of your Exchange ActiveSync users, you can create Exchange ActiveSync mailbox policies. These policies help you apply specific settings to a single user or group of users. Available settings include the following:
Require a password.
Require an alphanumeric password.
Allow attachments to be downloaded to the device.
Allow access to Microsoft Windows SharePoint® Services documents.
Enable device encryption.
For more information about Exchange ActiveSync mailbox policies, visit Managing Exchange ActiveSync with Policies.
For more information about how to use the Exchange Management Console to manage an Exchange ActiveSync user, see the following topics:
Remotely Enforced Device Security Policies
Exchange Server 2003 SP2 and Exchange Server 2007 help you configure and manage a central policy that requires all mobile device users to protect their device with a password to access the Exchange server. Not only that, you can also specify the length of the password, require use of a character or symbol, and designate how long the device has to be inactive before prompting the user for the password again.
An additional setting, "wipe device after failed attempts," allows you to delete all data on the device after the user repeatedly enters the wrong password a specified number of times. The user will see alert dialog boxes warning of the possible wipe and providing the number of attempts left before it occurs.
Another setting allows you to specify whether noncompliant devices can synchronize. Devices are considered noncompliant if they do not support the security policy you have specified. In most cases, these are devices not configured with the Exchange Server Messaging and Security Feature Pack.
Remote Device Wipe
The remote wipe feature helps you manage the process of remotely erasing lost, stolen, or otherwise compromised mobile devices. If the device was connected using Direct Push technology, the wipe process will be initiated immediately and should take place in seconds. If you have used the enforced lock security policy, the device is protected by a password and local wipe, so the device will not be able to perform any operation other than to receive the remote wipe notification and report that it has been wiped.
Device security policies are managed from Exchange System Manager Mobile Services Properties window. Here you can:
View a list of all devices that are being used by any user.
Select or deselect devices to be remotely erased.
View the status of pending remote-erase requests for each device.
View a transaction log that indicates which administrators have issued remote-erase commands, in addition to the devices to which those commands pertained.
Certificate-Based Authentication
If Secure Sockets Layer (SSL) basic authentication does not meet your security requirements and you have an existing Public Key Infrastructure (PKI) using Microsoft Certificate Server, you may want to use the certificate-based authentication feature in Exchange ActiveSync. If you use this feature in conjunction with other features described in this document, such as local device wipe and the enforced use of a power-on password, you can transform the mobile device itself into a smart card. The private key and certificate for client authentication is stored in memory on the device. However, if an unauthorized user attempts to brute-force attack the power-on password for the device, all user data is purged, including the certificate and private key.
Microsoft has created a tool for deploying Exchange ActiveSync certificate-based authentication. To download the tool and documentation from the Microsoft Download Center, go to https://go.microsoft.com/fwlink/?LinkId=63271.
S/MIME-Encrypted Messaging
The Messaging and Security Feature Pack for Windows Mobile 5.0 provides native support for digitally signed, encrypted messaging. When encryption with the Secure/Multipurpose Internet Mail Extension (S/MIME) is deployed, end users can view and send S/MIME-encrypted messages from their mobile device.
The S/MIME control:
Is a standard for security enhanced e-mail messages that use a PKI to share keys.
Offers sender authentication by using digital signatures.
Can be encrypted to protect privacy.
Works well with any standard-compliant e-mail client.
For guidance on how to implement the S/MIME control with Exchange Server 2003 SP2, see the Exchange Server Message Security Guide at https://go.microsoft.com/fwlink/?LinkId=63272.
SMS 2003 Device Management Feature Pack
The Systems Management Server 2003 Device Management Feature Pack (DMFP) gives SMS 2003 the power to manage mobile devices running Microsoft Windows® CE (3.0 or later) and Windows Mobile software for Microsoft Pocket PCs (2002 or later), and Windows Mobile 5.0 and Windows Mobile Pocket PC Phone Edition 5.0. Using the DMFP, IT administrators can capture the asset characteristics, configuration settings, and security policies of mobile devices, and to update or deploy new applications with minimal interruption to the end user, dramatically reducing the cost of deploying and managing devices.
Using the DMFP, you can do the following:
Discover and collect inventory information from mobile and on-site clients running Windows CE 4.2 or Windows Mobile 2003 software for Pocket PC and Pocket PC Phone Edition, and Windows Mobile 5.0 and Windows Mobile Pocket PC Phone Edition 5.0.
Through complementary partner offerings, discover and collect inventory from mobile and on-site clients running Windows CE 3.0, Pocket PC 2002 software, Windows Mobile 5.0 and Windows Mobile Pocket PC Phone Edition 5.0, and Windows Mobile software, including smart phones.
Distribute software updates and applications to these devices.
Support regional roaming scenarios for SMS package downloads by referring clients to local distribution points.
Implement password policy by enforcing secure passwords for these devices.
Deploy the SMS client software to devices with an ActiveSync connection to a computer running the SMS Advanced Client.
Use HTTP or secure HTTP (HTTPS) to communicate with the SMS server infrastructure.
Using these technologies, you can control mobile devices using Microsoft operating systems and software. Exchange Server’s device management capabilities are the minimum required set of capabilities to achieve the Standardized level in the Infrastructure Optimization Model.
Phase 4: Deploy
The goal of the Deploy Phase is to implement the selected technologies or features required to support your device management strategy. Because corporate network configurations and security policies vary, the deployment process will vary for each mobile messaging system installation. This deployment process includes the required steps and the recommended steps for deploying a mobile messaging solution that uses Exchange Server 2003 SP2 and Windows Mobile 5.0–based devices.
For detailed guidance to deploy a secure mobile messaging using Microsoft Exchange Server, see the Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2.
Operations
The goal of ongoing Operations is to ensure a secure and highly available mobile messaging environment for end users. Visit the Windows Mobile Center at Microsoft TechNet for guidance on maintaining your mobile messaging environment.
Further Information
For more information on managing mobile devices, visit Microsoft TechNet and search on “mobile device management.”
To see how Microsoft handles one aspect of mobile device management, go to https://www.microsoft.com/technet/itshowcase/content/mobmess_tcs.mspx.
Checkpoint: Centralized Management of Mobile Devices
|
Requirement |
|---|---|
|
Installed software to discover and track the mobile devices in your organization. |
|
Implemented password-controlled access. |
|
Established centralized data and software synchronization. |
|
Ensured that decommissioned devices are free of company information. |
If you have completed the steps listed above, your organization has met the minimum requirement of the Standardized level for Centralized Tracking, Management, and Upgrading of Mobile Devices. We recommend that you follow additional best practices for mobile device management addressed in the Windows Mobile Center at Microsoft TechNet.
Go to the next Self-Assessment question.
Requirement: Identity Validation, Data Protection, and Data Backup of Mobile Devices
Audience
You should read this section if you do not have user identity validation and data protection and backup for mobile devices.
Overview
Lost or stolen mobile devices can compromise sensitive corporate information and allow access to corporate networks. You must protect these resources by implementing thorough policies and software. In this section of the guide we address areas where you can take steps to secure corporate information and networks in your organization. These areas are:
User access
Passwords
Device lockout
Certificates
Data access
Data encryption
Remote device wipe
For information about mobile device security from Microsoft, go to https://www.microsoft.com/windowsmobile/business/5/default.mspx.
Phase 1: Assess
The primary goals in the Assess Phase are to determine how users are accessing data and to collect the business needs for ensuring secure access and data protection for mobile devices. Most of these principles were addressed during the Plan and Deploy Phases of the Centralized Management of Mobile Devices section of the guide. This capability in the Infrastructure Optimization Model reinforces the importance of data security and controlled user access.
Phase 2: Identify
During the Identify Phase you will identify technology options and develop requirements to meet your organization’s requirements for user access, data security, and data backup. Refer to the Requirement: Centralized Management of Mobile Devices section of this guide for detailed information about the technologies and features available in Microsoft Exchange Server 2003, Microsoft Exchange Server 2007, and Systems Management Server 2003
Also, visit the Windows Mobile Center at Microsoft TechNet for more details.
Phase 3: Evaluate and Plan
The goal of the Evaluate and Plan Phase is to develop a detailed strategy for secure user access, data security, and data protection of managed mobile devices. High-level considerations of these objectives are described in this section.
User Access
The first defense against unauthorized access to information on a mobile device is user identification and validation using passwords or certificates.
Passwords
Access to each of your organization’s mobile devices should require a password. Passwords can be either simple (numeric) or strong (comprised of letters, numbers, and special characters), as dictated by your company password policy.
Device Lockout
If a user repeatedly fails to enter the correct password a predetermined number of times (usually three to five) the mobile device should enter a lockout state where further access can only be accomplished by an administrative reset.
Certificates
A public key certificate, usually called simply a certificate, is a digitally signed statement that is commonly used for authentication and to secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. The issuing certification authority (CA) digitally signs the certificates, and they can be issued for a user, a computer, or a service. You must have procedures in place to revoke certificates when a mobile device is lost or stolen.
Data Access
Whenever a mobile computer is outside the organization's physical security boundary, theft of the computing device and the data it contains is a primary concern. If theft does occur, the initial problem of lost data escalates to potentially having an unauthorized person penetrate the network via remote dial-up or wireless networking. Because of their design, mobile computers and many new types of portable devices have a higher risk of being stolen than a nonportable device. Often these machines hold important company data and represent a security risk if stolen.
Data Encryption
You can use an encrypted file system on mobile devices to obscure data on the hard drive, which renders it useless to anyone without proper credentials. This protects the data from access by someone that obtains a device that has been lost or stolen.
Remote Device Wipe
Features of Exchange Server remote device wipe allow an administrator or an authorized user the ability to remotely erase all information on a mobile device, effectively returning it to its initial default state.
As a reactive measure, you can use remote wipe to block unauthorized access to the data on a lost or stolen mobile device. You would use remote wipe if you conclude that other access provisions such as passwords or certificates were not in place, or had been compromised. In this scenario, a command to wipe the device is sent from a server.
Proactively, remote wipe can be another tool you can use along with user authentication and data encryption to ensure that access to corporate data and the company network can be blocked if the mobile device has been stolen. In this scenario the device self-wipes based on the imbedded security policy.
Data Backup
Data backup of sensitive messaging, calendar, and company address list data is a critical first step for data backup on mobile devices. Data backup for synchronized messaging, address list, and calendar information is performed by the Exchange Server infrastructure via standard server backup and recovery procedures. See the Standardized level Infrastructure Optimization Backup and Restore Services for Critical Servers section of this guide for more details. Additionally, software is available from Microsoft partners to perform device-level backups of nonsynchronized data.
Phase 4: Deploy
The goal of the Deploy Phase is to implement your organization’s selected strategy for managing user access, data security, and data backup. For detailed guidance on deploying the technologies outlined in this guide, go to the Step-by-Step Guide to Deploying Windows Mobile-based Devices with Microsoft Exchange Server 2003 SP2.
Operations
The goal of ongoing Operations is to ensure secure user access, data security, and data backup in your mobile messaging environment. Visit the Windows Mobile Center at Microsoft TechNet for guidance on maintaining your mobile messaging environment.
Further information
For more information on remote wipe, go to
https://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/7b2cb90a-67f5-45d5-8c7a-26309faa7d9e.mspx?mfr=true.
Checkpoint: Identity Validation, Data Protection, and Data Backup of Mobile Devices Checkpoint
|
Requirement |
|---|---|
|
Established and are enforcing a password-access policy or using public key certificates for user identification. |
|
Encrypted all transfers for data distribution to, and data backup from, mobile devices. |
|
Implemented device lockout on mobile devices. |
|
Ensured that company information can be removed with remote wipe in case a mobile device is lost or stolen. |
If you have completed the steps listed above, your organization has met the minimum requirements of the Standardized level for Identity Validation, Data Protection, and Data Backup of Mobile Devices. We recommend that you follow additional best practices for mobile-device management addressed in the Windows Mobile Center at Microsoft TechNet.
Go to the next Self-Assessment question.
Requirement: Consolidation of Desktop Images to Two Operating System Versions
Audience
You should read this section if you are managing more than two operating system versions in your desktop environment.
Overview
There are several things to consider when deploying multiple operating systems within an enterprise. These include:
Maintenance of multiple standard images.
Availability of patches and updates.
Cost of extended maintenance contracts.
User productivity.
Application compatibility.
This guide highlights the high-level considerations for consolidating your desktop images to two operating systems.
Phase 1: Assess
The goal of the Assess Phase in image consolidation is to determine the current number of operating systems managed by your organization. We recommend that you use a tool to automate the inventory process, such as Systems Management Server (SMS) 2003, the Application Compatibility Toolkit or the Windows Vista Hardware Assessment.
Phase 2: Identify
In the Identify Phase you begin to determine the dependencies of the operating systems discovered with your inventory and how they relate to applications used and hardware specifications.
Phase 3: Evaluate and Plan
The purpose of the Evaluate and Plan Phase is to discuss options in consolidating your desktop images to two standard images. These include the management benefit, business benefit, and prioritization of user upgrades. This section introduces many considerations of evaluating the consolidation of desktop images.
Multiple Standard Images
The topic "Defined Standard Images for Desktops and Laptops" earlier in this document describes the advantages of establishing and maintaining a standard desktop operating system image, and the pros and cons of thick, thin, and hybrid images. The creation and maintenance of multiple thick and hybrid images, and accompanying cost, increases associated with each different operating system that your organization must support. To move from the Basic level in the Infrastructure Optimization Model to the Standardized level you should limit the number of operating systems that you must support in your organization to a maximum of two, although limiting to only one version offers substantial benefits and is preferable.
Patches and Updates
Patches and updates to operating systems and applications must be tested before they are distributed to users. The time and expense involved in testing an application increases with each operating system on which the application runs. Simply tracking all available patches and updates can become time-consuming and costly.
Maintenance Contracts
If your organization purchases maintenance contracts for operating systems and applications, the costs can increase as the number of supported software titles increases. This is especially true of legacy operating systems and applications, software that has been retired by the vendor.
User Productivity
When users move from one operating system to a different one, there is a learning period that impacts productivity. The user has to stop and think about how to perform a task that was reflexive on the previous operating system.
Application Compatibility
As applications and operating systems are upgraded, data files on which those applications operate are not always compatible with newer versions. Standardizing on one or two operating systems and their compatible applications will minimize the problems of incompatible data files.
Exceptions
It is not always possible to make one or two operating systems work for every situation or organizational need. The use of mobile devices is increasing; their operating systems will differ from a desktop or laptop computer. Some end users, such as graphic designers or engineers, remote users, or vendors connecting to your network may have different operating systems on their computers than the organization standard. It is the IT department’s responsibility to account for these exceptions and to adapt the recommendations of this guide to these situations.
Other exceptions may be outside the responsibility of the IT department. Software-development organizations need to ensure that the software they are developing will run on multiple operating systems. A test lab that evaluates new operating systems and upgrades falls outside the scope of this document.
Phase 4: Deploy
After you have determined the strategy for image consolidation, during the Deploy Phase you take into account how images are built, deployed, and maintained. See the Computer Imaging System Feature Team Guide found in BDD 2007, or see the Requirement: Defined Standard Images for Desktops and Laptops resource guidance.
Operations
After a successful operating system consolidation project has been completed, it should be understood that the release of new desktop operating system products and technologies will require careful consideration. Preparing for the new operating system will mean in most cases that the older of the two active operating systems will be phased out as the new operating system image is introduced. This ensures that the benefit of maintaining two operating system images remains intact.
Checkpoint: Consolidation of Desktop Images to Two Operating System Versions
|
Requirement |
|---|---|
|
Implemented an image-consolidation strategy. |
|
Reduced the number of production operating systems to no more than two. |
If you have completed the steps listed above, your organization has met the minimum requirement of the Standardized level for Consolidation of Desktop Images to Two Operating System Versions in the Desktop, Device and Server Management capabilities of the Infrastructure Optimization Model. We recommend that you follow additional best practices for image consolidation and management addressed in the Computer Imaging System Feature Team Guide found in BDD 2007.
Go to the next Self-Assessment question.