Sherry Kissinger at myITforum.com

Enable DCOM

Vince Tran found an excellent utility for Enabling DCOM on Windows 2000/XP using SMS.  No more visiting the computer, going to dcomcnfg, +Component Services, +Computers, right-click my computer, Default Properties tab, and check 'enable dcom'.  All Vince needed help with from me was the mof edit so he could get the collection of "Machines with dcom disabled".  Since enabling dcom via script has been mentioned enough in the forums, etc, this was too cool not to share.  Vince doesn't yet have a blog, so he gave me permission to outline the steps.

• Grab the free utility DCOMBOB
• The command to enable dcom is DCOMBOB enable   (to disable, is DCOMBOB disable)  A reboot is required before you'll actually see it enabled or disabled in dcomcnfg.
• The MOF edit is below; once machines start reporting, just create a collection of machines where EnableDcom=N, and target them with the ad.

//  <:[-<>>>>>>>>>>>>Start>>-DCOM Enabled-<<Start<<<<<<<<<<<<<<<<<>-]:>
//`'`*._.*`'`*-
//  DCOM Data Class
//`'`*._.*`'`*-
#pragma namespace("\\\\.\\root\\cimv2")
#pragma deleteclass("DCOMEnabled", NOFAIL)
 [DYNPROPS]
 class DCOMEnabled
{
 [key] string KeyName="";
 string  EnableDCOM;
};
 
//`'`*._.*`'`*-
//  Instance of DCOM
//`'`*._.*`'`*-
 
 [DYNPROPS]
 instance of DCOMEnabled
{
 KeyName="EnableDcom";
 [PropertyContext("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\OLE|EnableDCOM"),
 Dynamic, Provider("RegPropProv")] EnableDCOM;
};
 
//`'`*._.*`'`*-
//  DCOM Reporting Class
//`'`*._.*`'`*-
 
 #pragma namespace("\\\\.\\root\\cimv2\\SMS")
 
 [SMS_Report(TRUE), SMS_Group_Name("DCOMEnabled"),SMS_Class_ID("SMSExpert|DCOMEnabled|1.0")]
 class DCOMEnabled : SMS_Class_Template
{
 [SMS_Report(TRUE),key] string KeyName;
 [SMS_Report(TRUE)]  String EnableDCOM;
};
//  <:[-<>>>>>>>>>>>>>>>>>END>>-DCOM Enabled-<<END<<<<<<<<<<<<>-]:>

Stamp your MSI/MST

In an email list, I mentioned that we 'stamp' our repackaged .MSI's or any .MST's (Transforms) we modify with some additional registry keys, and the mini.mof has a section for pulling in those registry keys.

If you have a formal enough process for packaging applications for distribution with SMS, and are already in the habit of creating or modifying a Transform, this may be an additional step you want to incorporate into your processes.

First, decide where in the registry this information should be stored.  We chose a location which was already used previously for other automation scripts and tags.  I suggest you modify the attached .reg, and the below Mof edit to match, to use your Company Name.  For the purposes of this blog entry, both the .reg and the .mof edit are for the fictional company "MyCompany"

Create or edit your transform; the instructions below presume you are using Installshield.  Since that's what I have available to me, I could write out the step-by-step instructions.  If you use a different Transform editor, please note the instructions may not be 1:1 applicable.  While editing the .MST; go to Setup Design.  Right-click, New Feature; call it _MyCompany.  DisplayName=_MyCompany.  Display=Not Visible.  Required=Yes.  Right-click the new _MyCompany, New Component, call it _MyCompany.  Go to Registry Data within that component; on the right-hand side, right-click within the registry area and Import REG File..., and import the attached (after you've customized it) registry edit.  Save the Transform.

You would do the above steps for every transform you create or edit; it would just become part of your documented routine for packaging.

The next step is to extend hardware inventory with the below mof edit. Now you'll be able to run reports, similar to the attached, to report on specific MSI attributes, as well as exactly when a product was installed on that particular computer.

//----------------------
// MyCompany Package Information
//----------------------

#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass ("win32Reg_MyCompanyPackages",NOFAIL)
[ dynamic,
  provider("RegProv"),
  ClassContext("local|HKEY_LOCAL_MACHINE\\Software\\MyCompany\\Packages")
]
class Win32Reg_MyCompanyPackages
{
    [key]                              string    AppNameAndVersion;
    [PropertyContext("Build")]         string    Build;
    [PropertyContext("InstallDate")]   string    InstallDate;
    [PropertyContext("InstallTime")  ]  string    InstallTime;
    [PropertyContext("ProductCode")]    string    ProductCode;
    [PropertyContext("ProductName")]    string    ProductName;
    [PropertyContext("ProductVersion")] string    ProductVersion;
    [PropertyContext("Release")]        string    Release;
    [PropertyContext("Transforms")]     string    Transforms;
    [PropertyContext("UpgradeCode")]    string    UpgradeCode;
};

#pragma namespace ("\\\\.\\root\\cimv2\\sms")
#pragma deleteclass ("win32Reg_MyCompanyPackages",NOFAIL)
[ SMS_Report     (TRUE),
  SMS_Group_Name ("MyCompany Package Info"),
  SMS_Class_ID   ("MICROSOFT|MyCompany_PACKAGE_INFO|1.0") ]

class Win32Reg_MyCompanyPackages : SMS_Class_Template
{
    [SMS_Report (TRUE), key ] string AppNameAndVersion;
    [SMS_Report (TRUE)      ] string Build;
    [SMS_Report (TRUE)      ] string InstallDate;
    [SMS_Report (TRUE)      ] string InstallTime;
    [SMS_Report (TRUE)      ] string ProductCode;
    [SMS_Report (TRUE)      ] string ProductName;
    [SMS_Report (TRUE)      ] string ProductVersion;
    [SMS_Report (TRUE)      ] string Release;
    [SMS_Report (TRUE)      ] string Transforms;
    [SMS_Report (TRUE)      ] string UpgradeCode;
};
//----------------------
// MyCompany Package Information
//----------------------

Simplified SMS 2003 Site-to-Site rights

This is a tip I was given years ago, so I forget who it was, so I'm sorry I can't give credit where credit is due.  In SMS 2003, using Advanced Security, it is the computer account which usually handles site-to-site communications.  Whenever you build a new site, you could add that computer account to it's immediate hierarchical neighbors' local groups and any AD Ous it may need access to.  But here's a simplified method for ensuring all of your sites can talk to all of your other sites.

• Create an AD Group called something like "SMS_Site_Servers"
• Add to this AD Group the computer accounts of all of your site servers
• Grant this AD Group the rights necessary to the AD System Management Container
• Add this domain AD Group, SMS_Site_Servers, to the local Administrators group of each Site (PS: you could instead put the group in the appropriate SMS_ local groups needed; but Administrators group is simpler, and I'm going for simple here)

Done!  The only caveat is that new group memberships of a computer/server aren't acknowledged until a reboot, so you'll have to reboot your SMS servers to get that group membership active.  But from now on, whenever you need to add a new SMS Site Server (Secondary site, DP, etc); Add that computer's AD Account into SMS_Site_Servers; add SMS_Site_Servers to the local Administrators group of the new SMS Site Server, one reboot--and rights are taken care of.