Patch Management Using Systems Management Server 2003
Chapter 4 - Appendices
On This PageAppendix A: Project GuidanceThe purpose of this appendix is to offer high-level project management and testing guidance for deploying the components of the Patch Management Using Systems Management Server 2003 Solution Accelerator. The solution accelerator contains:
The project guidance offered by this appendix is based on Microsoft Solutions Framework (MSF). MSF provides proven practices for planning, building, and deploying a variety of technology solutions, combining aspects of software design and development, and building and deploying infrastructure into a single project life cycle for guiding technology solutions of all kinds. For more information about MSF, see the Microsoft Solutions Framework Web site at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx. Solution Accelerator OverviewThe Patch Management Using Systems Management Server 2003 Solution Accelerator focuses on the Microsoft-recommended four-phase patch management process, which is designed to give your organization control over the deployment and maintenance of interim software releases into your production environment. The Microsoft-recommended patch management process contains the following four phases:
Project Team PrerequisitesMembers of the team working on a patch management project should:
Solution Project Phases and ActivitiesAlthough MSF prescribes a five-phase process model, complete with major milestones and interim milestones, at a high level those phases fit into four major areas of concentration: planning, building, deploying, and operating. PlanningTo prepare for patch management, you should fully understand the business importance of patch management for your specific environment and the technologies and skills that you have (or do not have) in place for performing proactive patch management. Next, you can assign teams and responsibilities to ensure that patch management is carried out effectively, as part of normal operations. Successful patch management, like security and operations, is achieved through a combination of people, processes, and technology. To determine how much effort to put into patch management, first assess the impact of poor (or reactive) patch management on the business, then determine if your organization’s capabilities and infrastructure are sufficient to perform patch management effectively. Use this information to decide what your organization’s goals for proactive patch management should be. The business problem should document the impact to a business when it does not have a proactive patch management process in place. Reacting to security problems (whether they are attacks by computer viruses and worms or targeted attacks instigated by perpetrators inside or outside an organization) only after they occur, can negatively affect the financial health and the related business goals and objectives of an organization. Security programs such as patch management are more easily accomplished with executive support. Technology professionals can drive patch management infrastructure, tools, techniques, and processes; but without executive sponsorship, it will be difficult to ensure sufficient resources and broad support for areas such as security policy, which must be applied across the organization to be truly effective. Clear business goals and supporting objectives should be created and understood by the sponsoring executives. After you have executive sponsorship and buy-in, the first step in deploying an effective patch management solution within your organization will be to summarize the tools and assets that are available to be used in patch management, and then to assess the capabilities of the organization to perform patch management. Operations AssessmentThrough MOF, Microsoft offers a well-established process for conducting an operations assessment. The primary reason for conducting such an assessment is to ensure that you have the operational and technical capability to deploy software updates in your environment. Organizations that want to implement patch management should possess the process maturity to support the following:
The operations assessment is conducted through:
The results from these activities are then compared with the minimum set of practices and standards necessary to successfully implement patch management. Technical AssessmentThe assessment team must also complete a technical assessment of the IT infrastructure, reviewing the implementation of SMS to verify that it is operated and maintained according to best practices. This service operates on top of other core IT services (for example, TCP/IP), which must also be verified for proper operation. The patch management solution architecture is optimized for specific configurations of SMS to support patch management. These include service pack installation, site structure, and file amendments, all of which are discussed within this solution accelerator. BuildingRecommendations for solution design are described in this solution accelerator, which includes solution architectural elements as well as specific design guidance. Using the recommendations and guidelines in this solution accelerator, the design team will create a design document that outlines how to perform the activities required during each phase of patch management. For example, the design document might describe how the organization registers for, receives, and monitors information about new software updates. Although the design may vary according to the size and complexity of the organization, follow the recommendations documented in the solution accelerator to ensure best results. Testing the solution prior to deployment is a basic requirement. The test environment should be configured to replicate the production environment to the greatest extent possible. It should include a representative sample of older and newer hardware, various baseline and line-of-business (LOB) applications, and servers. For each test described in the solution accelerator, there is information about the specific equipment and technical configurations required to perform each test, the steps that are required to carry it out, and the expected results. Process testing is also required, although it is more conceptual in nature. To test operational processes, it may be necessary to simulate the various tasks required: from discovery of a new (simulated) software update through approval, testing, and deployment. DeployingDeploying a software update management solution is likely to require a phased approach. First, the organization must upgrade its service management functions to fill gaps identified during assessment. Next, the technical aspects of the solution are installed and configured, including the software update distribution infrastructure. Finally, the patch management process is layered over the hardware and software components to implement the service features, including patch subscription, notification, approval, testing, and deployment. This approach is described in greater depth elsewhere in this solution accelerator. The solution deployment may include training activities for IT staff, as well as technical tasks. Staff members must become familiar with the necessary responses to a patch notification and how to integrate these responses into their operational environment. In addition to training for these specific tasks, you might want to provide more generalized operations training. This can be accomplished through formal training using courseware developed by Microsoft and delivered through a variety of vendors. Applicable courses include Course 1737: Microsoft Operations Framework Essentials, Course 1787: Microsoft Operations Framework Changing Quadrant, and Course 2126: Managing a Microsoft Windows 2000 Network Environment. For more information about these courses, see the Microsoft Training Web site at http://www.microsoft.com/learning/training/default.asp. Depending upon the solution architecture and configuration, some user training may also be required if manual interaction is required to install software updates on user devices. OperatingOperations refers to the daily, weekly, monthly, and as-needed tasks required to deploy software updates into a production environment and how each of these tasks is allocated to a MOF Team Model role cluster. This solution accelerator includes a chapter (Chapter 3, “Operational Guidance”) on those tasks. The project team must review these tasks to determine which will be required for the patch management solution being created. Note that the list of tasks in Chapter 3, “Operational Guidance,” is not exhaustive and it is likely that additional tasks may be required, depending upon your environment, existing management procedures, and corporate standards. After the list of tasks has been identified, the project team will work with the IT organization customer to allocate roles and responsibilities to groups or to individuals who will then carry out those tasks as part of their usual duties. In many cases, training, as described in the previous Deploying section, will be required to ensure that the roles meet performance requirements. Operations ChecklistThe Operations Checklist should be used to ensure that your organization has the minimum operational processes necessary to support patch management. If any of these processes are missing, you should determine whether they can be designed and implemented within the scope of the patch management project or if you will need to start a separate—and more wide-ranging—review of service management. The checklist is presented in the format of a table, as shown in Figure 4.1. Change ManagementThe organizational changes subject to the change management process include hardware, software, system components, documents, and processes—anything deliberately introduced into the IT environment that could affect its functioning as reflected in the service level agreements (SLAs) existing between the IT department and the business it serves. Information in Table 4.1 is based on the MOF Change Management service management function (SMF). For more information about the Change Management SMF, see the SMF Web site at http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/default.mspx. Table 4.1.
Configuration ManagementConfiguration management is a critical process responsible for identifying, controlling, and tracking all versions of hardware, software, documentation, processes, procedures, and all other inanimate components of the information technology (IT) organization. The goal of configuration management is to ensure that only authorized components are used in the IT environment and that all changes are recorded and tracked. Information in Table 4.2 is also based on the Configuration Management SMF. Table 4.2.
Release ManagementRelease management is responsible for deploying changes into an IT environment. After one or more changes are developed, tested, and packaged into releases for deployment, release management is responsible for introducing these changes and managing their release into the IT environment. Release management also contributes to the efficiency of change introduction by combining changes into one release and deploying them together. Information in Table 4.3 is based on information from the Release Management SMF. For more information about the Release Management SMF, see the SMF Web site at http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/default.mspx. Table 4.3.
Appendix B: Mapping Patch Management to MOFMSM version 3.0 includes a high-level, four-stage Process Model for patch management, as illustrated in Figure 4.2.  Figure 4.2. The Microsoft patch management four-stage Process Model This model is a higher-level abstraction of the full end-to-end MOF patch management Process Model used in earlier versions of the MSM patch management offerings. The four phases of the model map to the full end-to-end process as follows:
Configuration management, which spans all phases of both models, is a critical process responsible for identifying, controlling, and tracking all versions of hardware, software, documentation, processes, procedures, and all other inanimate components of the IT organization. The following figure illustrates how the high-level, four-phased process maps to the MOF patch management Process Model used in earlier versions of the MSM patch management offerings.  Figure 4.3. Comparison of high-level four-phase process to the MOF patch management Process Model Appendix C: Modifying SMS_Def.mof to Inventory the RegistryThe following is a sample SMS_Def.mof file showing modification to inventory registry. //------------------------------------------------------
// Identifying Servers running TS in Application Mode
// Terminal Services- Obtain TSEnabled from Registry
// Terminal Services- Obtain TSAppCompat from Registry
//------------------------------------------------------
#pragma namespace (“\\\\.\\root\\cimv2”)
// grab the TS Enabled and TS Application Mode
[DYNPROPS]
class TSAPPMode
{
[key]
string keyname=””;
string TSEnabled;
string TSAppCompat;
};
[DYNPROPS]
instance of TSAPPMode
{
keyname=”TSAPPMode”;
[PropertyContext(“local|HKEY_LOCAL_MACHINE
\\SYSTEM\\CurrentControlSet\\Control
\\Terminal Server|TSEnabled”),Dynamic,
Provider(“RegPropProv”)]
TSEnabled;
[PropertyContext(“local|HKEY_LOCAL_MACHINE
\\SYSTEM\\CurrentControlSet\\Control
\\Terminal Server|TSAppCompat”),Dynamic,
Provider(“RegPropProv”)]
TSAppCompat;
};
#pragma namespace (“\\\\.\\root\\cimv2\\sms”)
[
SMS_Report(TRUE),
SMS_Group_Name(“TS Application Mode”),
SMS_Class_ID(“MICROSOFT|TSAPPMode|1.0”)
]
class TSAPPMode : SMS_Class_Template
{
[SMS_Report(TRUE),key]
string keyname;
[SMS_Report(TRUE)]
string TSEnabled;
[SMS_Report(TRUE)]
string TSAppCompat;
};Appendix D: Emergency Security ResponseOverviewEven with the best patch management process, your technology environment can still be attacked. Not all vulnerabilities are resolved by the application of security updates; some vulnerabilities may be related to weak computer security configurations. Alternatively, a software vulnerability could be exploited before a security update is available or even before it has been publicly reported—otherwise known as a “zero day” attack. Perhaps a vulnerability that has recurred in the environment has been exploited before being addressed. Regardless, it is not necessary to understand why you are vulnerable to realize that an emergency security response may be required. To deal with the emergency effectively, you need to have an incident response plan in place. This appendix identifies key ways to prepare for an emergency, provides suggestions for setting up an incident response plan, and gives prescriptive measures and ideas about how to minimize impact and take control during an emergency situation. EvaluationThe first step in the emergency response scenario is to identify and define the emergency. If you are in an emergency situation, the attack requires immediate attention. How vulnerable are all of your systems? You need to be able to immediately prioritize the resources needed to fight the emergency based on asset valuation. When your intrusion detection system or other indicators tell you that you are under attack, as part of your evaluation, you need to:
Notification and EscalationProper communication is critical to managing an attack. Depending on the type of attack, determine exactly who needs to know that an attack is underway. During a targeted attack, do not tip off the attacker with company-wide communications; keep attack communications contained to the people who have a need to know. With a virus or worm, company-wide communication that reaches all employees both onsite and remote may be appropriate. Keep in mind that communication technologies may also be under attack. You should have a contingency plan in the event any of your usual communication methods are unavailable. Be sure to communicate appropriately. Make the communication to the point, informational, and constructed to alleviate any panic. If you have specific company guidelines for communications, make sure to follow them so that the recipients trust the message. These guidelines may need to be revised to accommodate emergency situations. It is very important that all those who are involved in an incident response communicate effectively. Doing so will help ensure that decisions are made without duplicating effort and that no steps of the process are missed. The incident response team should be the focal point for all communications. Contact Your Technology VendorsIf a Microsoft product is involved in the attack, notify Microsoft Product Support Services at (866) PC SAFETY or (866) 727-23389 for free virus-related and security update–related support in the United States and Canada. For other locations, contact Microsoft Product Support Services worldwide at http://support.microsoft.com/common/international.aspx. If you have Microsoft Premier Support, contact your Technical Account Manager using his or her contact information. Microsoft has security and incident response experts who can help you understand an attack and assist you throughout the incident response process. Contact Law Enforcement AgenciesIntrusions can be a criminal event. Consider notifying the appropriate law enforcement agency if you are under attack, and understand and comply with your local jurisdictional requirements for involving the authorities and informing those who may be affected by the intrusion. Many government agencies have extensive experience (likely more experience than your organization will have) assisting organizations with Internet intrusions and subsequent prosecution. Reduce your risk in an emergency situation by involving them! Note In the United States, there are several agencies that you can contact when you are under attack. The United States Department of Justice provides information on how to report Internet-related crime at http://www.usdoj.gov/criminal/cybercrime/reporting.htm. Contact Legal CounselIt is a good idea to contact your organization’s legal counsel at this point to collaboratively determine if legal prosecution is a possibility after the event, depending on the nature of the attack. If legal prosecution is an option, throughout the event process your organization should maintain a log of the business impact of the attack (damages) and take additional steps to protect the evidence, such as:
Isolate and ContainAlthough uptime is very important in most environments, keeping computers available during an attack may result in more damage. Balance the impact of an ongoing attack with the impact of an appropriate defense. Attacks that destroy, manipulate, or divulge sensitive data or that require a full computer reinstallation to recover from may merit taking computers offline to protect them. Less intrusive attacks, such as some denial of service attacks, may not require a response this severe. In most cases, the source of an attack should be removed from the network to isolate and minimize proliferation, regardless of the type of attack. When you take extreme measures that affect the business, you should track them closely so that they can be successfully removed after the incident is resolved. The following are several activities that you can perform to isolate and contain an attack:
If you are the target of a distributed denial of service attack, you might want to work with your ISP on a coordinated response. There are also specific items you may want to turn off or disable during an attack. Some of these are:
For more information about using IPSec to block ports and secure a server, see “Using IPSec to Lock Down a Server” at http://www.microsoft.com/technet/solutionaccelerators/network/security/ipsecld.mspx. For scripts that can start and stop services remotely, visit the TechNet Script Center at http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx. Scripts that can remotely change passwords and lock accounts are also available from the TechNet Script Center at http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx. Analyze and RespondTo be able to recover effectively from an attack, you need to determine how seriously your environment has been compromised. This will help identify how to contain and minimize the risk, how to recover, with whom you should communicate the incident, and whether to seek legal redress. In general you should attempt to:
RemediationIf computers need to be recovered from an attack, it is always best to rebuild a fresh system. Consider rebuilding a fresh system with new hard disks using your up-to-date, secure baseline. Ensure that you change any local passwords and address the vulnerability that was exploited during the attack. You should also change administrative and service account passwords elsewhere in your environment. If Microsoft or your virus vendor provides a recommended way of cleaning a computer from a virus or worm that does not require a full reinstallation, this option might be preferable because of the time and cost saved. However, there is always a chance that an attacker opened several back doors after your computer was compromised during an attack (for example, several viruses leave back doors for future exploits). When a computer has been compromised by an attack of any kind, the safest way to return it to service is to reinstall the operating system, reload applications from a known good backup or baseline that applies an up-to-date security policy, and ensure the exploited vulnerability has been addressed. Even though it might be tempting to address the compromise quickly and get the computer back on the network, it is risky to do so because it is impossible to determine what back doors or changes to the computer the attackers have left. CERT maintains a list of steps for recovering from a system compromise, which is available at http://www.cert.org/tech_tips/root_compromise.html. Accelerated Release ManagementWhen fixing problems across the environment in response to an attack, use your current change and release management processes as a guide, performing only those steps that are required to quickly and effectively respond to the attack. If an attack can be resolved with the application of a security update or countermeasure, determine how to quickly install it throughout the organization. The risk of the vulnerability being exploited during an attack is significantly higher than normal, so you might decide to perform only basic testing during an emergency. Take all of the company’s technology assets into account. During an attack, not all assets may be connected to the network—for example, remote users may need to be addressed. If you deploy an accelerated release, you may need to deploy it again when remote computers return, or have them install it before they can connect. If you do not have a software update distribution infrastructure in place, consider sending users to Windows Update or Office Update to install a security update or putting an emergency Software Update Services infrastructure in place. As long as your connection to the Internet has not been disabled during an attack, computers can download and install the security update from Windows Update. This method is extremely useful for remote users. You can communicate to them the importance of the security update and give instructions for using the Windows Update Web site. As a last resort, if an attack affects network services, consider deploying a security update manually. This would involve visiting each computer and applying the release, or providing CDs and installation information to all users in a coordinated manner. Monitoring and De-EscalationAfter you have installed a release in the production environment, continue to monitor your computers and network. Watch for a recurrence of any attack signatures determined when learning about the attack. As well as monitoring existing servers, it is important that you monitor the environment as a whole to ensure that new computers added to the network are not vulnerable, thereby enabling the attack to start again. De-escalation indicates a return to normal business operations. De-escalation typically occurs when none of the parties involved in the incident are identifying or reporting new information. Post-Incident Activities and ReviewAfter the incident is over and the attack is no longer considered an active threat, there are a few wrap-up activities that should be performed, including:
Appendix E: Building a List of Reference ComputersThe following is a sample script that should be run on your SMS 2003 primary site servers to create a collection that contains all representative computers in the environment. This resulting collection is effectively a replacement for the “pre-production collection” that Setup creates by default. This collection allows you to test a software update on a representative set of computers. When prompted by the script for the collection name, type Security Update Inventory Tool (preproduction) for the name. Note If the collection does not appear in the SMS Administrator console after refresh, you should stop and restart the SMS_EXECUTIVE service. The new collection should then appear. Option Explicit ‘On Error Resume Next ‘ comment out for debugging, uncomment for error handling Const sScriptTitle = “Create OS Sample Collections Script” Const cnSamples = 3 ‘ default number of samples ‘ since this is VB Script, there are no types. Type information is included for readability. Dim oLocator ‘ as SWbemLocator Dim oServices ‘ as SWbemServices Dim eInstances ‘ as SWbemObjectSet Dim oInstance ‘ as SWbemObject Dim oWMIContext ‘ as SWbemNamedValueSet “””””””””” First we need to set up our connection to the SMS Provider ‘ Create locator, needed to connect to the WMI namespace Set oLocator = CreateObject(“WbemScripting.SWbemLocator”) If Err.Number <> 0 Then ReportError “Windows Management (WMI) is not installed on this computer.” ‘ Ask the user for the name of the Site Server ‘ you can also get this from the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\AdminUI\Connection \Server Dim sSiteServer, msg msg = “This script will create collections based on site membership. “ msg = msg & “Enter the name of the site server where the collections will be created: “ ‘ see if we can guess the site server name Dim oShell Set oShell = CreateObject(“WScript.Shell”) sSiteServer = oShell.RegRead(“HKLM\SOFTWARE\Microsoft\SMS\AdminUI\Connection \Server”) If Err.Number = 0 Then sSiteServer = Mid(sSiteServer,3,Len(sSiteServer)-3) Else sSiteServer = vbNullString End If Set oShell = Nothing If sSiteServer = vbNullString Then sSiteServer = InputBox(msg,sScriptTitle,sSiteServer) End If If sSiteServer = vbNullString Then WScript.Quit(0) ‘ Connect to the SMS Site Server, we’re using integrated security here but you do have the option ‘ of specifying a user name and password as well. Set oServices = oLocator.ConnectServer(sSiteServer, “root\sms”) If Err.Number <> 0 Then ReportError “Could not connect to SMS Site Server on: \\” & sSiteServer & vbCrLf & Err.Description “””””””””””””” ‘ Ask it for the the name of the SMS Provider Set eInstances = oServices.ExecQuery(“select SiteCode, Machine from SMS_ProviderLocation where ProviderForLocalSite=TRUE”) If Err.Number <> 0 Then ReportError “Could not find SMS Provider on SMS Site Server: \\” & sSiteServer Dim sSiteCode Dim sProvMachine ‘ There should be only one of these instances For Each oInstance In eInstances sSiteCode = oInstance.SiteCode sProvMachine = oInstance.Machine Exit For Next ‘ Connect to the SMS Provider Set oServices = oLocator.ConnectServer(sProvMachine, “root\sms\site_” & sSiteCode) If Err.Number <> 0 Or oServices Is Nothing Then ReportError “Could not connect to SMS Provider on: \\” & sProvMachine End If ‘ We’re done with the WMI Locator now Set oLocator = Nothing ‘ Create context object for use with logging Set oWMIContext = CreateObject(“WbemScripting.SWbemNamedValueSet”) ‘ get the machine name Dim oWshnetwork Set oWshnetwork = CreateObject(“Wscript.Network”) ‘ These two context properties are needed for proper auditing oWMIContext.Add “ApplicationName”, sScriptTitle oWMIContext.Add “MachineName”, oWshNetwork.ComputerName Set oWshNetwork = Nothing Dim eOSTypes, oOSType, oColl, oRuleCls, oRule, oPath, oNewColl2Sub, oWMIContextLimit Dim nRulecount, nMaxRulecount, nInstanceCount Dim sCollName, nSamples If WScript.Arguments.Count > 0 Then sCollName = WScript.Arguments(0) Else sCollName = InputBox(“Enter the name of the collection to create.”,sScriptTitle,””) End If If Len(sCollName)=0 Then WScript.Quit(0) End If If WScript.Arguments.Count > 1 Then nSamples = CInt(WScript.Arguments(1)) Else nSamples = cnSamples ‘ use default End If Set oWMIContextLimit = CreateObject(“WbemScripting.SWbemNamedValueSet”) oWMIContextLimit.Add “InstanceCount”, CInt(nSamples) ‘ get list of sample operating systems set eOSTypes = oServices.ExecQuery(“select distinct Caption, CSDVersion, Version, OSLanguage from SMS_G_System_Operating_System”) If Err.Number <> 0 Or eOSTypes Is Nothing Then ReportError “Could not retrieve list of operating systems” End If ‘ get new or existing collection and set up set oColl = Nothing set eInstances = oServices.ExecQuery(“select * from SMS_Collection where Name=””” & sCollName & “”””) If Err.Number <> 0 Or eInstances Is Nothing Then ReportError “Error querying for collection” End If If eInstances.Count = 0 Then set oColl = oServices.Get(“SMS_Collection”).SpawnInstance_ oColl.Name = sCollName oColl.Comment = “Contains a representative sample of each operating system and version.” oColl.RefreshType = 1 oColl.OwnedByThisSite = True Else For each oColl in eInstances Exit For Next End IF Set eInstances = Nothing set oRuleCls = oServices.Get(“SMS_CollectionRuleDirect”) ‘ query for each type of OS and add systems, take the systems that most recently reported inventory Dim sSelect, sOrderBy, sWhere sSelect = “select sys.ResourceID, sys.Name from SMS_R_System sys join SMS_G_System_Operating_System os on sys.ResourceID=os.ResourceID “ sSelect = sSelect & “ join SMS_G_System_WORKSTATION_STATUS stat on sys.ResourceID=stat.ResourceID “ sOrderBy = “ order by stat.LastHardwareScan DESC” nMaxRulecount = nSamples*eOSTypes.Count ReDim arRules(nMaxRulecount-1) nRulecount=0 If nMaxRulecount > 0 Then ‘ walk through each operating system type and find healthy examples For each oOSType in eOSTypes sWhere = “ where os.Caption=””” & oOSType.Caption & “”” and os.Version=””” & oOSType.Version & “”” and os.OSLanguage=” & CStr(oOSType.OSLanguage) If IsNULL(oOSType.CSDVersion) Then sWhere = sWhere & “ and os.CSDVersion is NULL” else sWhere = sWhere & “ and os.CSDVersion=””” & oOSType.CSDVersion & “””” End If set eInstances = oServices.ExecQuery(sSelect & sWhere & sOrderBy,,48,oWMIContextLimit) If Err.Number <> 0 Or eInstances Is Nothing Then ReportError “Error querying for machines” End If nInstanceCount = 0 for each oInstance in eInstances set oRule = oRuleCls.SpawnInstance_ oRule.RuleName = oInstance.Name oRule.ResourceClassName = “SMS_R_System” oRule.ResourceID = oInstance.ResourceID set arRules(nRulecount) = oRule nRulecount = nRulecount + 1 nInstanceCount = nInstanceCount + 1 If nInstanceCount >= nSamples Then exit for next set eInstances = Nothing Next End If Set eOSTypes = Nothing ‘ if we didn’t get all the samples, resize the array If nMaxRulecount > nRulecount Then Redim preserve arRules(nRulecount-1) End if ‘ set the rules array into the rules property and then save the collection oColl.CollectionRules = arRules set oPath = oColl.Put_( ,oWMIContext) If Err.Number <> 0 Then ReportError “Could not create or update collection.” ‘ put this site in the tree (top level) by creating an association with COLLROOT Set oNewColl2Sub = oServices.Get(“SMS_CollectToSubCollect”).SpawnInstance_ oNewColl2Sub.parentCollectionID = “COLLROOT” oNewColl2Sub.subCollectionID = CStr(oPath.Keys.Item(“CollectionID”)) oNewColl2Sub.Put_ ,oWMIContext If Err.Number <> 0 Then ReportError “Could not create collection association.” “” End of Script WScript.Quit(0) “””””””” “ Error handling routine Sub ReportError(Msg) Dim oError Set oError = CreateObject(“WbemScripting.SWbemLastError”) If Not oError is Nothing Then MsgBox Msg & vbCrLf & oError.GetObjectText_(),vbCritical,sScriptTitle Else MsgBox Msg & vbCrLF & Err.Text & “ : “ & Err.Number,vbCritical,sScriptTitle End If WScript.Quit(1) End Sub
|
In This Article
|
