Best Practices
Always configure advertisements to download content
Configuring to Download content from distribution point and run locally is more secure because Configuration Manager 2007 verifies the package hash after the content is downloaded and discards the package if the hash does not match the hash in the policy. If you configure the advertisement to Run program from distribution point, no verification takes place and attackers can tamper with the content. If you must run the program from the distribution point, use NTFS least permissions on the packages on the distribution points and use Internet Protocol security (IPsec) to secure the channel between the client and the distribution point and between the distribution point and the site server.
Do not allow users to interact with programs if run with administrative rights is required
When you configure a program, you can set the option Allow users to interact with this program so that users can respond to any required prompts in the user interface. If the program is also configured to Run with administrative rights, an attacker at the computer running the program could use the user interface to escalate privileges on the client computer. You should use Windows Installer-based setup programs with per-user elevated privileges for installations that require administrative credentials but that must be run in the context of a user who does not have administrative credentials. Using Windows Installer per-user elevated privileges provides the most secure way of deploying applications with this requirement.
Do not create subcollections if you need to restrict software distribution on them
An advertisement to a collection with subcollections is sent to all members of the collection and subcollections, even if the administrator has only the Advertise right to the collection (not the subcollections). Any administrator who can link a collection to another collection can cause that collection to receive the advertisements targeted to the other collection, even if they do not have Advertise permissions on any collection. For this reason, you should watch for the addition of subcollections to collections with advertisements, and be cautious of whom you give permission to for reading collections that receive advertisements.
Set package access permissions at package creation
Changes to the access accounts on the package files (as opposed to the distribution point shared folders) become effective only when you refresh the package. Therefore, you should set the package access permissions carefully when you first create the package, especially if the package is large, if you are distributing the package to many distribution points, or if your network capacity for package distributions is limited. To quickly initiate the refresh of all distribution points, you can use the Update Distribution Points task for the package.
Secure software at the package access level
By default, the package files on distribution points are fully accessible by administrators and readable by users. Users with administrative rights on client computers can set the client to join any site, even if the computer is not within the boundaries of the site. When the clients have joined the site, they can receive any software distributions that are available at that site and for which the computer or user meets the qualifications of the relevant collections. For this reason, software that should be limited to specific users should be secured at the package access level to those users, rather than being limited by site availability or collection criteria. However, restricting the access of the Internet Guest account to packages will cause package access to fail for Internet-based clients. For more information, see Example Package Access Scenarios.
After upgrading, if you had packages in SMS 2003, update all packages
SMS 2003 (released version) used MD5 to hash packages;Configuration Manager 2007 and SMS 2003 service packs later than SP1 use SHA-1. To rehash all of the packages with SHA-1, you should update all packages created in SMS 2003 (released version) that have not already been updated with an SMS service pack. Failing to do so might cause clients to discard valid packages if the advertisement is configured to download the package and run it locally.
Best Practices for Distribution Points
Remove the distribution point role from the site server By default, the site server is set up as a standard distribution point. However, you should assign this role to other site systems and remove it from the site server to reduce the attack surface. Clients have no valid reason to talk directly to the site server or any role configured on the site server. This is especially important if you chose to enable Background Intelligent Transfer Service (BITS) on the distribution point, because installing Internet Information Services (IIS) to create a BITS-enabled distribution point greatly increases the attack surface of the site system.
Do not create distribution point shares or branch distribution points on Internet-based clients
Although Configuration Manager 2007 might not block you from doing so, creating any type of distribution point on an Internet-based client greatly increases your attack surface and should be avoided. Create distribution points only on site systems that can be managed within the intranet or the perimeter network.
After switching to a custom Web site, remove the default virtual directories
When you change from using the default Web site to using a custom Web site, Configuration Manager 2007 does not automatically remove the old virtual directories. You should manually remove the virtual directories created under the default Web site. This is especially important if you configured the distribution point to Allow clients to connect anonymously (Required for mobile device clients) while using the default Web site and then you disable anonymous connections after switching to the custom Web site. In this case, the old virtual directories will still be configured for anonymous access. For the list of virtual directories created on BITS-enabled distribution points, see About BITS-Enabled Distribution Points.
Implement access controls to protect branch distribution points Branch distribution points can be installed on any Configuration Manager 2007 client, including Microsoft Windows XP Professional workstation computers. Workstation computers are generally not subject to the same physical access controls as server computers, so you must monitor your usage of branch distribution points. Do not distribute sensitive source files to branch distribution points if there is a risk of an attacker stealing the hard drive or the entire branch distribution point. You should configure all advertisements so that clients download packages from a branch distribution point and run them locally rather than running them across the network. Configuration Manager 2007 verifies the hash on downloaded packages and discards any packages it cannot verify, but there is no package verification on packages run from the distribution point.
Enable the encrypted mode for Application Virtualization Streaming–enabled distribution points
In Configuration Manager 2007 R2, when you configure an Application Virtualization Streaming–enabled distribution point, you have the option of choosing Real Time Streaming Protocol (RTSP) or RTSP over TLS (RTSPS). Enabling encryption helps protect against attackers tampering with the data stream.
Security Issue
The following issue has no mitigation.
Packages are not validated until after they are downloaded Configuration Manager 2007 validates the signatures on packages only after they have been downloaded to the client cache. If an attacker has tampered with a package, the client could waste considerable bandwidth in downloading the package only to have it discarded due to an invalid signature.
Privacy Information
Software distribution allows you to run any program or script on any client in the site. Configuration Manager 2007 has no control over what types of programs or scripts you run or what type of information they transmit. During the software distribution process, Configuration Manager 2007 might transmit information between clients and servers that identify the computer and logon accounts.
Configuration Manager 2007 maintains status information about the software distribution process. Software distribution status information is not encrypted during transmission unless you enable native mode. Status information is not stored in encrypted form in the database.
Status information is stored in the site database and deleted by default every 30 days. The deletion behavior is configurable by setting both the Status Filter Rule properties and the site maintenance task. No status information is sent back to Microsoft.
The use of Configuration Manager 2007 software installation to remotely, interactively, or silently install software on clients might be subject to software license terms for that software and is separate from the Software License Terms for Configuration Manager 2007. You should always review and agree to the Software Licensing Terms prior to installing the software using Configuration Manager 2007.
Software distribution does not happen by default and requires several configuration steps. Before configuring software distribution, consider your privacy requirements.
January 16, 2010
Choose Between a Standard and Branch Distribution Point
Before deciding to protect any distribution points, you need to know the following information:
The location of all distribution points in the site
The location of all distribution points in the hierarchy if you support roaming
The location and available bandwidth of any slow network links
The largest package sizes you tend to distribute
You should consider protecting a distribution point if any of the following are true:
The distribution point is across a slow network link from other clients in the site
The distribution point is a branch distribution point
You frequently distribute large packages and want only clients closest to the distribution point to download content from it
You should be careful about protecting all distribution points in the site for the following reasons:
If all distribution points in the site are protected but not all boundaries are assigned to protected distribution points, a client belonging to an unassigned boundary will be unable to access any distribution points and the package will fail.
If a client roams to a new site and the package is not available in the resident site, the client will attempt to fall back to the assigned site but will fail if all of the distribution points in the assigned site are protected. For more information about roaming scenarios involving protected distribution points.
If you protect your distribution points, for each advertisement or software update deployment that you create, you must consider whether to allow clients to fall back to unprotected distribution points when the content is not available on the protected distribution point. Before making the decision, consider the following factors:
If the package is very large and would consume too much bandwidth, you can prevent fallback to unprotected distribution points, understanding that the clients might not receive the content at all.
If the package is small or if the content is critical, you can allow fallback to unprotected distribution points.
The location of all distribution points in the site
The location of all distribution points in the hierarchy if you support roaming
The location and available bandwidth of any slow network links
The largest package sizes you tend to distribute
You should consider protecting a distribution point if any of the following are true:
The distribution point is across a slow network link from other clients in the site
The distribution point is a branch distribution point
You frequently distribute large packages and want only clients closest to the distribution point to download content from it
You should be careful about protecting all distribution points in the site for the following reasons:
If all distribution points in the site are protected but not all boundaries are assigned to protected distribution points, a client belonging to an unassigned boundary will be unable to access any distribution points and the package will fail.
If a client roams to a new site and the package is not available in the resident site, the client will attempt to fall back to the assigned site but will fail if all of the distribution points in the assigned site are protected. For more information about roaming scenarios involving protected distribution points.
If you protect your distribution points, for each advertisement or software update deployment that you create, you must consider whether to allow clients to fall back to unprotected distribution points when the content is not available on the protected distribution point. Before making the decision, consider the following factors:
If the package is very large and would consume too much bandwidth, you can prevent fallback to unprotected distribution points, understanding that the clients might not receive the content at all.
If the package is small or if the content is critical, you can allow fallback to unprotected distribution points.
Choose between Server and Server Share Distribution Point
Server
Advantages:
1. Configuration Manager 2007 automatically creates a common package share when the first package is copied to the distribution point.
2. There is less chance of failing to copy a package because Configuration Manager 2007 creates a new SMSPKGx$ share when more space is needed.
3. The server can be configured as a branch distribution point.
4. The server can be configured to support Internet-based clients.
Disadvantages
1. Every time Configuration Manager 2007 copies a package to the distribution point, it chooses the NTFS drive with the most free space, making it difficult to determine which drive letter will hold the new package.
2. Configuration Manager 2007 can take over all available NTFS disk space on the server.
Server Share
Advantages
Configuration Manager 2007 will not use space reserved for other functions on other partitions.
Disadvantages
1. Administrator must manually create a shared folder before creating the new site system server share.
2. Configuration Manager 2007 might fail to create a package if there is no free space on the partition where the shared folder was created.
3. Configuration Manager 2007 does not create a data discovery record (DDR) to monitor the health of the site system.
4. The server share cannot be configured as a branch distribution point.
5. The server share cannot be configured to support Internet-based clients.
Advantages:
1. Configuration Manager 2007 automatically creates a common package share when the first package is copied to the distribution point.
2. There is less chance of failing to copy a package because Configuration Manager 2007 creates a new SMSPKGx$ share when more space is needed.
3. The server can be configured as a branch distribution point.
4. The server can be configured to support Internet-based clients.
Disadvantages
1. Every time Configuration Manager 2007 copies a package to the distribution point, it chooses the NTFS drive with the most free space, making it difficult to determine which drive letter will hold the new package.
2. Configuration Manager 2007 can take over all available NTFS disk space on the server.
Server Share
Advantages
Configuration Manager 2007 will not use space reserved for other functions on other partitions.
Disadvantages
1. Administrator must manually create a shared folder before creating the new site system server share.
2. Configuration Manager 2007 might fail to create a package if there is no free space on the partition where the shared folder was created.
3. Configuration Manager 2007 does not create a data discovery record (DDR) to monitor the health of the site system.
4. The server share cannot be configured as a branch distribution point.
5. The server share cannot be configured to support Internet-based clients.
Difference between Refresh DP and Update DP: SMS/SCCM
Updating distribution points includes these steps:
Recopy the source files for a package to the compressed version located at the site where the package originated.
Copy the source files to the local distribution points.
Replicate the new compressed version to all child sites that are selected as distribution points for this package.
Refresh the package includes this step:
Replicate the existing compressed version of the source files to selected distribution points.
Recopy the source files for a package to the compressed version located at the site where the package originated.
Copy the source files to the local distribution points.
Replicate the new compressed version to all child sites that are selected as distribution points for this package.
Refresh the package includes this step:
Replicate the existing compressed version of the source files to selected distribution points.
MSI Packaging Tools
Windows Installer technology was introduced in the Windows 2000 platform to take some of the pain out of deploying and managing Windows applications across an enterprise. In previous versions of Windows (NT/9x), developers usually created installation packages using a variety of proprietary tools developed by third-party vendors such as InstallShield Software and Wise Solutions. To bring some kind of consistence to this situation, Microsoft included Windows Installer as a core service (msiexec.exe) within Windows 2000 to install, repair, and remove software based on instructions contained in .MSI files. These .MSI files are basically database files that contain all the information an application needs in order to install a packaged application. Then once you package your application you can deploy it using Group Policy by one of two methods:
Assigning an application. You can assign a .MSI package to either a computer or a user. If you assign it to a computer, the packaged application installs the next time the computer reboots. If you assign it to a user, the application typically installs when the user tries to run it from the Start menu or tries to open a file that has a file extension associated with the application.
Publishing an application. You can publish a .MSI package to users only. This provides the user with an option within Add or Remove Programs in Control Panel that lets them manually install the application if they want to.
Once Microsoft included Windows Installer technology in Windows 2000, they also made it their policy to include .MSI installation packages in all applications they developed for Windows. What they didn’t include at the time was a tool of their own for repackaging traditional Setup-based applications into .MSI packages. Instead, Microsoft decided to include a “light” version of WinINSTALL called WinINSTALL LE (WinINSTALL Limited Edition) in the Valueadd folder on the Windows 2000 product CD. Administrators could then use WinINSTALL LE to repackage legacy applications into .MSI packages that could then be deployed using Group Policy. Microsoft apparently also decided to leave it to third-party vendors to develop full-featured .MSI packaging tools to meet the needs of customers who needed to deploy third-party and custom applications across their enterprise.
As a result of this decision, the marketplace has a number of competing .MSI packaging tools and .MSI authoring environments available at present, and the remainder of this article looks at three popular packaging tools that are available. Some of these tools are free while others are commercial products with varied pricing and licensing requirements, check out their websites for details. Using any of these tools can make your life easier as an administrator of a large, Windows-based network, since they save you the time of having to visit desktops to install the applications that make your business work.
Advanced Installer
The free version of Advanced Installer from Aphyon is powerful and easy to use, but if you want to get into advanced packaging tricks like setting attributes, installing .NET assemblies, installing ODBC drivers and so on, then you’ll need to opt for the more powerful Professional version instead. Aphyon also provides optional features through add-ons that can be purchased extra. One cool feature of Advanced Installer is that it stores its Windows Installer project files in XML format. This simplifies versioning of packages you’re developing and lets you keep track of packages using a version control system. Another feature of Advanced Installer is that you can perform most actions from the command line. This allows you to automate application packaging using scripts, something that can be useful if you have a large enterprise with many applications to deploy. The current version of Advanced Installer is version 2.3 and you can download it here for Windows 2000/XP platforms.
WinINSTALL MSI Packager
WinINSTALL MSI Packager from Software OnDemand is a tool from the same evolutionary line that produced WinINSTALL LE discussed previously. Because of this heritage, WinINSTALL MSI Packager is a popular .MSI packaging tool today in many enterprise environments. Not only can the tool be used to easily package applications for deployment, it also lets you test them against standards like the Microsoft Logo Certification. This ensures your packaged applications will install properly on the latest Windows operating systems. The current version of WinINSTALL MSI Packager is version 8.6 and you can download an evaluation version of this software here. Software OnDemand also has two other tools you may want to look at: the upscale WinINSTALL 8.6 full product that lets you not only deploy applications but also manage them, and WinINSTALL LE 2003 which is the latest incarnation of the free “light” version that was included on the Windows 2000 product CD.
Wise for Windows Installer
Wise for Windows Installer from Wise Solutions Inc. is another application packaging tool that is popular in some enterprise environments. This tool fully complies with Microsoft’s .MSI standards while also extending the capabilities of .MSI packages without making changes to their native format. The result is a powerful tool that can be used to deploy legacy, Web-based, and .NET applications quickly and easily. Enterprises that make heavy use of Microsoft SQL Server for back-end databases and Internet Information Services (IIS) 5.0 or 6.0 for front-end Web applications should take a close look at this product. If all you want to do is package applications into .MSI format, this tool is so easy and intuitive to use you hardly need a manual. Wise for Windows Installer comes in several editions including Standard, Professional, and Enterprise editions to meet your deployment needs according to your budget. Wise for Windows Installer is also part of a larger family of Wise Solutions products that includes Wise Package Studio and Wise Installation System 9.0.
Assigning an application. You can assign a .MSI package to either a computer or a user. If you assign it to a computer, the packaged application installs the next time the computer reboots. If you assign it to a user, the application typically installs when the user tries to run it from the Start menu or tries to open a file that has a file extension associated with the application.
Publishing an application. You can publish a .MSI package to users only. This provides the user with an option within Add or Remove Programs in Control Panel that lets them manually install the application if they want to.
Once Microsoft included Windows Installer technology in Windows 2000, they also made it their policy to include .MSI installation packages in all applications they developed for Windows. What they didn’t include at the time was a tool of their own for repackaging traditional Setup-based applications into .MSI packages. Instead, Microsoft decided to include a “light” version of WinINSTALL called WinINSTALL LE (WinINSTALL Limited Edition) in the Valueadd folder on the Windows 2000 product CD. Administrators could then use WinINSTALL LE to repackage legacy applications into .MSI packages that could then be deployed using Group Policy. Microsoft apparently also decided to leave it to third-party vendors to develop full-featured .MSI packaging tools to meet the needs of customers who needed to deploy third-party and custom applications across their enterprise.
As a result of this decision, the marketplace has a number of competing .MSI packaging tools and .MSI authoring environments available at present, and the remainder of this article looks at three popular packaging tools that are available. Some of these tools are free while others are commercial products with varied pricing and licensing requirements, check out their websites for details. Using any of these tools can make your life easier as an administrator of a large, Windows-based network, since they save you the time of having to visit desktops to install the applications that make your business work.
Advanced Installer
The free version of Advanced Installer from Aphyon is powerful and easy to use, but if you want to get into advanced packaging tricks like setting attributes, installing .NET assemblies, installing ODBC drivers and so on, then you’ll need to opt for the more powerful Professional version instead. Aphyon also provides optional features through add-ons that can be purchased extra. One cool feature of Advanced Installer is that it stores its Windows Installer project files in XML format. This simplifies versioning of packages you’re developing and lets you keep track of packages using a version control system. Another feature of Advanced Installer is that you can perform most actions from the command line. This allows you to automate application packaging using scripts, something that can be useful if you have a large enterprise with many applications to deploy. The current version of Advanced Installer is version 2.3 and you can download it here for Windows 2000/XP platforms.
WinINSTALL MSI Packager
WinINSTALL MSI Packager from Software OnDemand is a tool from the same evolutionary line that produced WinINSTALL LE discussed previously. Because of this heritage, WinINSTALL MSI Packager is a popular .MSI packaging tool today in many enterprise environments. Not only can the tool be used to easily package applications for deployment, it also lets you test them against standards like the Microsoft Logo Certification. This ensures your packaged applications will install properly on the latest Windows operating systems. The current version of WinINSTALL MSI Packager is version 8.6 and you can download an evaluation version of this software here. Software OnDemand also has two other tools you may want to look at: the upscale WinINSTALL 8.6 full product that lets you not only deploy applications but also manage them, and WinINSTALL LE 2003 which is the latest incarnation of the free “light” version that was included on the Windows 2000 product CD.
Wise for Windows Installer
Wise for Windows Installer from Wise Solutions Inc. is another application packaging tool that is popular in some enterprise environments. This tool fully complies with Microsoft’s .MSI standards while also extending the capabilities of .MSI packages without making changes to their native format. The result is a powerful tool that can be used to deploy legacy, Web-based, and .NET applications quickly and easily. Enterprises that make heavy use of Microsoft SQL Server for back-end databases and Internet Information Services (IIS) 5.0 or 6.0 for front-end Web applications should take a close look at this product. If all you want to do is package applications into .MSI format, this tool is so easy and intuitive to use you hardly need a manual. Wise for Windows Installer comes in several editions including Standard, Professional, and Enterprise editions to meet your deployment needs according to your budget. Wise for Windows Installer is also part of a larger family of Wise Solutions products that includes Wise Package Studio and Wise Installation System 9.0.
Microsoft IT: Centralized Management Support Structure in detail
Service Desk
Microsoft IT currently uses a service desk team to create and assign tickets to incident and problem management teams. The service desk team documents all ticket activities, reports against SLAs, and collects metrics that can be used for problem management analysis and investigations. The service desk team also builds a knowledge database that supports repeatable process improvements and provides the Microsoft product groups with valuable feedback.
Incident Management
The primary goal of the incident management team is to restore normal service operation as quickly as possible and to minimize the adverse impact on business operations, thus maintaining the best possible levels of service quality and availability.
Problem Management
The objective of the problem management team in Microsoft IT is to minimize the adverse impact on the operational ability of a business due to incidents and problems caused by errors within the IT infrastructure, and to prevent the recurrence of incidents related to these errors. To achieve this goal, the problem management team seeks to establish the root cause of incidents and then initiate actions to improve or correct the situation.
Change Management
The Microsoft IT change management team provides a disciplined process for introducing required changes into a complex IT environment with minimal disruption to ongoing operations. The change management team is also closely aligned with the release management process and manages the release and deployment of changes into the production environment.
Service Level Management
Microsoft IT developed service level management in line with the requirements and priorities of the services documented and offered in the service catalog for the business, and the specific requirements of the negotiated SLAs. Microsoft IT uses the monitoring of a service against the requirements in real time, and the reporting and reviewing of key trends in historical data, to highlight and remove failures that affect the level of performance of the service.
Microsoft IT currently uses a service desk team to create and assign tickets to incident and problem management teams. The service desk team documents all ticket activities, reports against SLAs, and collects metrics that can be used for problem management analysis and investigations. The service desk team also builds a knowledge database that supports repeatable process improvements and provides the Microsoft product groups with valuable feedback.
Incident Management
The primary goal of the incident management team is to restore normal service operation as quickly as possible and to minimize the adverse impact on business operations, thus maintaining the best possible levels of service quality and availability.
Problem Management
The objective of the problem management team in Microsoft IT is to minimize the adverse impact on the operational ability of a business due to incidents and problems caused by errors within the IT infrastructure, and to prevent the recurrence of incidents related to these errors. To achieve this goal, the problem management team seeks to establish the root cause of incidents and then initiate actions to improve or correct the situation.
Change Management
The Microsoft IT change management team provides a disciplined process for introducing required changes into a complex IT environment with minimal disruption to ongoing operations. The change management team is also closely aligned with the release management process and manages the release and deployment of changes into the production environment.
Service Level Management
Microsoft IT developed service level management in line with the requirements and priorities of the services documented and offered in the service catalog for the business, and the specific requirements of the negotiated SLAs. Microsoft IT uses the monitoring of a service against the requirements in real time, and the reporting and reviewing of key trends in historical data, to highlight and remove failures that affect the level of performance of the service.
Subscribe to:
Posts (Atom)