August 2007 - Posts
If you have downloaded the 120-day trial version of Configuration Manager 2007 please read the release notes (ConfigMgr07Readme.htm in the root of the installation media). In fact, please read the release notes any time you install anything that has them!
We do release notes (relnotes in the writing jargon) because the main product documentation (core docs) have closed and we have an issue that:
a) Affects at least 80% of our target audience (SMS/ConfigMgr admins) or
b) Affects less than 80% of our target audience, but causes significant confusion or misunderstanding when working with the product.
What I mean by closed is...well, closed for us, the writers, to update. Our documentation is localized into many different languages and our localizers need time to translate the documentation into the various release languages in time for the major product milestones. The RTM version of the Configuration Manager Documentation Library was locked to updates by the writing team well before the RTM milestone was met for the product itself. We've been working on the next update to the core docs for quite some time now (notice the dramatic foreshadowing of great things to come).
When something has changed dramatically, or added to the product after we are "locked out" of the core docs, we SMS/ConfigMgr writers find sanctuary by calling on our "relnote fairy" Cathy Moya. Not only is Cathy our savior of all things relnote, she is our untiring (and I mean untiring...how many people respond immediately to e-mails sent at 1:20am?!) Configuration Manager writing team lead and security writer. While not related to this post, it should be noted that Cathy was one of the major driving forces behind how our massive TOC was designed and organized (no small feat).
Anyway, back to the Configuration Manager RTM relnotes. I'm making this post asking you to read them specifically because:
-
There are hotfixes listed in the relnotes that you need to apply to your servers before beginning Configuration Manager Setup, KB940848 (
http://go.microsoft.com/fwlink/?LinkId=98349) and KB941132 (
http://go.microsoft.com/fwlink/?LinkId=98350). The problem is, KB941132 is not live on the Web yet, but they are working on it. Even though the relnotes say you must install it, you can install the product without it for now, but you should check back later at the download link and install it when it becomes available. That hotfix fixes occasional crashes when browsing for Network Folders/Paths.
-
There is also information in the relnotes about the prerequisite component download page of the Configuration Manager Setup Wizard. This wizard page may surprise you during setup--because you won't find information about this setup wizard page in the RTM version of the core documentation (online or in the product)--the docs were locked before I could document this change.
I won't go into too many details here because the relnotes tell you everything you need to know about this download requirement, but basically due to redistribution restrictions we had to remove some external files from the product installation media that were previously stored there. These redistributable files are required for Configuration Manager Setup to succeed and are used mainly by client setup (ccmsetup.exe) as prerequisites for client installation. When a management point site system is installed, these client installation prerequisite files are copied from the primary or secondary site server to the management point to enable client installation processes.
For more information about prerequisites for installing Configuration Manager 2007, see "Prerequisites for Installing Configuration Manager" in the Configuration Manager Documentation Library on the DVD or on Microsoft TechNet at: http://go.microsoft.com/fwlink/?LinkID=83054.
Happy relnoting 
As Steve Kaczmarek (my boss) stated on the Configuration Manager Writer's Blog (http://blogs.technet.com/wemd_ua_-_sms_writing_team/archive/2007/08/27/configuration-manager-has-left-the-building.aspx) Configuration Manager has RTM'd and along with the product update, the product documentation is also being updated.
What used to be here: http://www.microsoft.com/technet/prodtechnol/sms/smsv4/smsv4_help/6ffe5c59-3858-49c5-83cb-16f63823187c.mspx
Is now here: http://technet.microsoft.com/en-us/library/bb680651.aspx
What's cool about the new link is that first of all, the content is in its proper home in TechNet, and secondly, that it contains new, never before seen, RTM content :-) It's nice to see the documentation in the proper place and without the [This is preliminary documentation and subject to change.] disclaimor!
Of course, even without the disclaimor you should know that the documentation library will be updated with new and improved topics every so often in the future. In fact, you'll notice something interesting on the home page of the Configuration Manager Documentation Library--a Version! The documentation currently online is the August 2007 version of the Configuration Manager Documentation Library. To see what we've been up to since the last version of the documentation set was published to the Web, check out the What's New in the Configuration Manager Documentation Library for August 2007 topic at http://technet.microsoft.com/en-us/library/bb680641.aspx. Besides being listed in the documentation library's What's New topic, updated topics have the month and year that they were last updated added to the top of the topic.
I'm pretty excited about this documentation update. Not just because it is the RTM documentation release, but because a lot of really cool and helpful documentation has been added since the RC release. The entire doc team has been very hard at work to constantly improve your documentation experience and I think it shows. I personally have a few favorites that I'm especially excited about and I hope you'll be just as excited to see. I've done a lot of work with SQL replication (even copy and paste SQL commands yay!), SPN's, Network Load Balancing and some other server-type updates and Carol Bailey has done an amazing job of describing how client roaming works in Configuration Manager to name a few of the updated topics in this release. Interested? Check out the What's New topic in the documentation library to read more.
Of course, we're still working on the documentation library in preparation for future updates and your feedback is always welcomed. If you would like to provide feedback or make a suggestion about the Configuration Manager Documentation Library, you can send an e-mail to smsdocs@microsoft.com, use the Microsoft Connect site at http://go.microsoft.com/fwlink/?LinkId=67307, or if you've already installed Configuration Manager 2007, you can right-click any node in the Configuration Manager console and click Give Feedback.
In my last post I talked about how to delete unwanted WMI classes using SMS 2003/Configuration Manager hardware inventory. In this post, I'll flip the coin to talk about how to ensure that WMI data class information is not lost--or at least not lost for long.
Every time a client computer's operating system starts, it checks the integrity of the WMI repository. If a client's WMI repository has become corrupted or somehow been damaged/deleted, the WMI repository is automatically rebuilt. The bad thing about this, from an SMS 2003 administrator's point of view at least, is that all that hard work you've put into modifying hardware inventory using custom data classes has now been lost. In order for clients to once again begin reporting the custom data class information, the client has to recompile a custom MOF file to re-create the custom data classes (not such a huge deal with Configuration Manager sites as the Configuration.mof is automatically compiled during client policy evaluation--including SMS 2003 clients assigned to Configuration Manager sites by the way).
So there's the background, here are the details. Each computer maintains a list of MOF files that it knows must be automatically re-compiled when the WMI repository is rebuilt. If you're curious, the list of autorecover MOF files stored in the registry can be viewed at: HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\autorecover mofs.
It's pretty easy to get your customized MOF file into this select group of files, just add the following line to the top your customized MOF file and WMI will add it to the list of autorecover MOF files in the registry:
#Pragma Autorecover
If that line is not present, and you are MOFCOMP'ing your MOF on a Windows Vista machine you will most likely recieve the following message:
WARNING: File <YourMOF>.mof does not contain #PRAGMA AUTORECOVER.
If the WMI repository is rebuilt in the future, the contents of this MOF file
will not be included in the new WMI repository.
To include this MOF file when the WMI repository is automatically reconstructed
place the #PRAGMA AUTORECOVER statement on the first line of the MOF file.
Done!
That's just Vista's way of telling you to read this post...OK not really. It is however, a reminder that if you want this WMI information to be rebuilt along with the other MOF files on 'the list' then you need to use the autorecover statement. If you are manually compiling the customized MOF file, just add the autorecover command to your MOFCOMP command like so:
MOFCOMP -Autorecover <YourMof>.MOF
Sounds great right?! Now you'll never lose that data class customization...of course there's a catch. WMI cannot recover MOF files located on a remote computer. When you use the autorecover command, MOFCOMP not only adds the name of the MOF file to autorecover, but it also takes note of the location of the MOF file. If you are going to use the autorecover command, you probably don't want to store the file in a temporary directory or somewhere that a user is going to inadvertantly delete it. Following WMI's lead, you can store the custom MOF file in the %WINDIR%\System32\WBEM directory before running MOFCOMP -Autorecover on it. You don't have to put it there, but just make sure that wherever you put it, it won't be deleted.
The #pragma deleteclass command is used in SMS/Configuration Manager hardware inventory modification to delete class information from WMI repositories. There are a couple of instances where this command comes in handy. If you are testing new hardware inventory modifications, and making changes to your mof edits during testing, you'll want to start off with a clean slate each time the client compiles the new mof file to avoid unforseen consequences. Or maybe you've just decided that you don't want to clutter up client WMI repositories with unnecessary class information and just want to delete it.
Note: When deleting WMI classes from clients that have already performed hardware inventories (especially if you have changed a Key field), you should also delete the class information stored in the site database as well. I won't go into that here, but Microsoft's delgrp.exe (involves going into SQL Server) and SMS Expert's SiteSweeper (easy way) can be used for that.
To delete the unneeded classes from a client's local system WMI repository, you need to manually compile a modified MOF (SMS_def.mof or 'mini-mof' for SMS 2003) or add the lines to the Configuration.mof (Configuration Manager) containing the now famous #pragma deleteclass line. Just open up your MOF/'mini-mof' and comment out the entire section for your targeted class-or delete the class totally and roll the dice that you'll never need it again. Make sure you use the #pragma deleteclass command on both the data and reporting classes as in the example below:
#pragma namespace("\\\\.\\root\\CIMV2")
#pragma deleteclass("ClassIDontLikeAnymore",NOFAIL)
#pragma namespace("\\\\.\\ROOT\\CIMV2\\SMS")
#pragma deleteclass("ClassIDontLikeAnymore",NOFAIL)
/*
...ClassIDontLikeAnymore information that I used to like, but now I don't. I've commented
it out in case I ever make friends with ClassIDontLikeAnymore again...
*/
P.S. Do not delete a data class unless you created it!
As with other tools released with SMS, you should only use tools that are either designed, or supported, for the specific product version you are installing. The Capacity Planning tool released for SMS 2003 SP1 should not be used to determine a capacity planning baseline for Configuration Manager 2007 site installations. The tool results should also be used only as very general guidance when used to determine capacity planning requirements for sites running SMS 2003 SP2 or SMS 2003 SP3 as the tool was not designed to consider post-SP1 features (OSDFP, DMFTP, AI, etc...).
Because the Capacity Planning tool released for SMS 2003 SP1 is not compatible with Configuration Manager 2007, it should not be used to determine suggested site capacity planning requirements for Configuration Manager 2007 sites. When the SMS 2003 Capacity Planning tool was developed, it was not designed to consider SUM, DCM, OSD, and many other changes (and new features) that were added in Configuration Manager. If you plan to deploy many of these new features you may require additional hardware, system resources, and network bandwidth above and beyond those required for SMS 2003 sites.
If you are planning to deploy Configuration Manager in a very large or complex environment (with hundreds of thousands of clients, or with thousands of packages, or with shorter policy polling intervals, etc...), you must plan to scale your resources accordingly. For example, when scaling capacity planning for a large site in a network bandwidth sensitive environment, not only software distribution package download should be carefully planned for, but you should also research and plan for the network bandwidth used for large volumes of: client policy downloads, inventory data reports, and large volumes of status and state messages.
There isn't a Capacity Planning tool released for Configuration Manager as of right now. However, the Configuration Manager help topic Configuration Manager Site Capacity Planning gives some general recommendations that can be used as a baseline to help determine site capacity planning information that is appropriate to your organization. This information is provided as general guidance only, because actual site capacity requirements will vary depending on factors such as the hardware used to host Configuration Manager site systems, your specific network environment, how many clients you will support, and how Configuration Manager features and client agents are implemented to support your business and technical objectives.
Lately a lot of people seem to be having some troubles in determining the appropriate subnet mask to use in site boundaries to assign clients when using IP subnet type boundaries (SMS site boundaries and roaming boundaries and Configuration Manager boundaries). When defining boundaries by IP subnets, you can't use superneted addresses--only standard subnet addresses like you would find in DHCP scopes can be used. To get around adding in a ton of IP subnets, you can just ensure that the required IP subnets have been configured for an AD site and use that as the boundary. When using IP subnets as a boundary, the subnets entered must be what clients resolve their subnet mask to be.
To determine the IP subnet that a client believes it lives in (and so what IP subnet to define as a boundary), you have to convert the IP address and subnet mask to binary numbers, keep the bits in the IP address that have bits set in the subnet mask, and then convert the result back to decimal. For example:
A client with a 10.10.67.66 IP address with a subnet mask of 255.255.255.0 would be in the 10.10.67.0 IP subnet...easy enough. Now, change the subnet mask to 255.255.255.192 and what subnet do you have now? <long pause as I get out my binary calculator and do some conversions and give myself a slight headache> Viola! 10.10.67.64. Easy enough right? Well, this is why there is a plethora of subnetting calculators out there I suppose. I just find it easier to run this script on a client computer
Subnetting and I have never really made friends so I love this script. It's an oldie first published in the SMS 2003 Concepts, Planning, and Deployment Guide and I make sure that I always keep this script handy when setting up my lab environments.
For best results, run this from the command prompt using the CSCRIPT option: CSCRIPT subnet.vbs. Get the script HERE (right click and select Save Target As... then change the extension from .txt to .vbs when you're ready to use it).
Here's the script (.vbs):
'subnet.vbs - displays the subnet for the computer's (or given) IP
' addresses and subnet masks
Set Arguments = Wscript.Arguments
If Wscript.Arguments.Count=2 Then
SubNetIT Arguments(0), Arguments(1)
Wscript.Echo ""
Else
Set loc = CreateObject( "WbemScripting.SWbemLocator" )
Set WbemServices = loc.ConnectServer( ,"root\cimv2" )
Set Adapters=WbemServices.ExecQuery( "Select * FROM" & _
" Win32_NetworkAdapterConfiguration" )
For Each Adapter in Adapters
If NOT IsNull( Adapter.IPAddress) Then
WScript.Echo "Description: ", Adapter.Description
SubNetIt Adapter.IPAddress(0), Adapter.IPSubnet(0)
WScript.Echo ""
End If
Next
WScript.Echo "You can also specify an address and subnet mask as " & _
"parameters to this script."
WScript.Echo ""
End If
WScript.Echo "At least one subnet must be a site's boundary for this computer"
WScript.Echo "to be assigned as a client."
Sub SubNetIt( Address, Subnet )
WScript.Echo "IP address: ", Address
WScript.Echo "subnet mask: ", Subnet
dim addressbytes(4)
dim subnetmaskbytes(4)
i=0
period = 1
while period<>len( address ) + 2
prevperiod=period
period = instr( period+1, address, "." ) + 1
if period = 1 then period = len( address ) + 2
addressbyte = mid( address, prevperiod, period-prevperiod-1 )
addressbytes(i)=addressbyte
i=i+1
wend
i=0
period = 1
while period<>len( subnet ) + 2
prevperiod=period
period = instr( period+1, subnet, "." ) + 1
if period = 1 then period = len( subnet ) + 2
subnetmaskbyte = mid( subnet, prevperiod, period-prevperiod-1)
subnetmaskbytes(i)=subnetmaskbyte
i=i+1
wend
subnet=""
for i=0 to 3
subnet = subnet & (addressbytes(i) AND subnetmaskbytes(i)) & "."
next
subnet = left( subnet, len(subnet)-1 )
WScript.Echo "subnet: ", subnet
End Sub
Hope it helps,
~Jeff
The Manageability TechCenter (http://technet.microsoft.com/manageability/default.aspx) was launched on Friday, August 17, 2007. It provides step-by-step guidance to help you more effectively manage the servers, desktop, and mobile computers in your organization.
The TechCenter contains sections on Getting Started with manageability, Configuration Management, Service Monitoring and Control, Storage Management, Consolidation and Virtualization, Troubleshooting and Help Desk. Each section contains Key Tasks and the Tools and Technologies/Products and Solutions that can be leveraged to successfully complete those tasks.
If you're new to enterprise systems management this is a great resource to get started. It's also a great place to go if you are already working in this arena and just want to learn more about the management technologies out there. This TechCenter has information about a ton of management technologies like Group policy, SMS 2003, ITMU, WSUS, SoftGrid, as well as new Microsoft System Center technologies, including System Center Configuration Manager 2007, System Center Operations Manager 2007, System Center Essentials, System Center Data Protection Manager, System Center Virtual Machine Manager 2007...and on and on.
Bottom line, if you're like me, and I know I am, and you're interested in manageability technologies, I think you're going to love this new TechCenter!
SMS 2003 or Configuration Manager Workgroup clients must be able to locate a server locator point for site assignment and their default management point in order to be managed. Because workgroup clients cannot query Active Directory Domain Services to find these site systems, in this situation, you have three options:
- The server locator point can be specified in the CCMSetup.exe installation command-line parameters. For more information about doing this see About Configuration Manager Client Installation Properties at: http://technet.microsoft.com/en-us/library/bb680980.aspx.
- You can manually publish the server locator point and management point in WINS. For more information about doing this see, How to Manually Add Configuration Manager Site Information to WINS at: http://technet.microsoft.com/en-us/library/bb632567.aspx.
- The server locator point can be specified in the LMHOSTS file on workgroup computers when a WINS server is not available. For more information about doing this see: remainder of this blog post
For Workgroup clients to locate these site systems, you need to enable some sort of NetBIOS name resolution. If you do not have a WINS server in place to support these clients, you can use an LMHOSTS file to enable site system name resolution for Workgroup clients.
To use the LMHOSTS file for site system name resolution, just add the following information (where <site code> is the site code for the primary site the client should be assigned to) to the LMHOSTS file. The LMHOSTS file is generally located in the client's %WINDIR%\system32\drivers\etc directory:
<IP address of MP> "MP_<site code> \0x1A" #PRE
<IP address of SLP> "SMS_SLP \0x1a" #PRE
NOTE: For the lmhosts file to work, it should not have a file extension. If you only find the lmhosts.sam (sample file) in that location just modify the file for your purposes and save it without the .sam file extension.
Because these names contain special characters, they must be enclosed in quotation marks. There must be a total of 20 characters within the quotation marks. There must be a total of 20 characters within the quotation marks. Yes, I wrote that twice on purpose for emphasis! If there aren't 20 characters in the name then using the LMHOSTS file for this will not work. Make sure that the backslashes are at the 16th character the end quotes should be after the 20th character.
Here's a handy trick for doing this that I picked up from How to write an Lmhosts file for domain validation and other name resolution issues (http://support.microsoft.com/kb/180094):
There must be a total of 20 characters within the quotations (the domain name plus the appropriate number of spaces to pad up to 15 characters, plus the backslash, plus the NetBIOS hex representation of the service type).
To help determine where the sixteenth character is, copy the following line to your Lmhosts file:# IP Address "123456789012345*7890" Line up the double quotation marks (") by adding or removing spaces from the comment line, and put the \ on the sixteenth column (the column marked with the asterisk). You must use spaces after the name and before the \, not a tab.
After that has been done, to verify it worked just open up a command prompt and enter the following command to refresh the name cache:
nbtstat -R
This is a fairly common MOF edit nowadays, and I thought I had this on my blog already. Anyway, I didn't so now I do
This MOF edit will inventory the client cache details for your SMS or ConfigMgr clients. It's only a reporting class so that means if you're going to inventory clients assigned to an SMS 2003 site, you don't need to manually compile the SMS_def.mof after adding this information (and you never have to do that for Configuration Manager sites).
//-------------------------------
// Client Cache Reporting Class
//-------------------------------
//The following line is not needed for Configuration Manager hardware inventory modifcations
#pragma namespace (\\\\.\\root\\cimv2\\sms)
[SMS_Report (TRUE),
SMS_Group_Name ("Client Cache"),
Namespace ("root\\\\ccm\\\\softmgmtagent"),
SMS_Class_ID ("MICROSOFT|CLIENT_CACHE|1.0") ]
Class CacheConfig : SMS_Class_Template
{
[SMS_Report (TRUE),key] string ConfigKey;
[SMS_Report (TRUE)] boolean InUse;
[SMS_Report (TRUE)] string Location;
[SMS_Report (TRUE)] uint32 Size;
};
You can get this MOF edit (as a .txt file) by right clicking HERE and selecting Save As...
Why? Using the simple recovery model improves performance and saves your server hard drive space from a useless (from an SMS recovery point of view) and possibly large, transaction log file. Using the SQL Server full recovery model for an SMS/Configuration Manager 2007 site database doesn't really provide any additional benefit. This is because SQL Server backups can't be used to recover a site (you are using the pre-defined backup site server maintenance task aren't you?). An SMS or ConfigMgr (yes, that's the abbreviation for it)-generated backup snapshot is required to recover a site because SQL Server backups do not back up everything required to restore a failed SMS/ConfigMgr site.
Quick definitions (according to Jeff): First, SQL Server databases always have a data file and a transaction log file. The data file is the data stored in the database. The transaction log file stores the details of pending database transactions that have yet to be saved to the data file. If the transaction log file for the site database is full, and you have set the SQL Server option for the transaction log files to grow automatically, the transaction log file may continue to grow until you run out of disk space. When a transaction log file grows until all of the available disk space is used, you can no longer perform any data modification operations on your database. With that in mind, the SQL Server full recovery model allows you to recover a database, and all of the pending transactions, from the last time you backed up the database. The SQL Server simple recovery model only allows you to recover the database to the point of your most recent backup so any pending transactions not committed to the database until after the backup is made are lost.
By default, SQL Server databases are configured to use the full recovery model. To most SQL Server administrators, no-one in their right mind would use the simple recovery model. For them, this is certainly understandable. In most cases, DBAs are responsible for having each transaction that occurs available for recovery in case of a database failure. For example, when those transactions represent revenue for a business using a SQL Server based Web application, losing a day's worth of transactions could result in a LOT of lost revenue. In our (SMS/ConfigMgr admins) case though, there is absolutely no option other than using an SMS/Configuration Manager site backup snapshot to recover a site and the additional overhead of the full recovery model is unnecessary. SMS backup snapshots are exactly what they sound like-snapshots. Whatever wasn't present when the last backup was successfully run won't be there when the backup is restored. The Configuration Manager Site Repair Wizard is capable of recovering some objects that weren't there when the site was backed up (for some sites), but not every pending transaction. So, in other words, back up your sites regularly using the predefined maintenance task for backing up sites!
Quick tidbits here before we get to the good stuff: If you're going use the SQL Server instance to only host SMS/ConfigMgr site databases (or some other database that can't benefit from the full recovery model) and want to do this, you can run the following procedures on the model database (before installing the site databases themselves) instead of the site database. Also, SQL Server 2005 database mirroring isn't supported on databases configured for the simple recovery model-but mirroring the site database isn't supported for either SMS or ConfigMgr anyway.
Steps to configure SQL Server to use the simple recovery model:
For SQL Server 2000:
- Start SQL Server Enterprise Manager, and then locate the SMS database.
- Right-click the SMS database, and then click Properties.
- In the DatabaseName Properties dialog box, click the Options tab.
- In the Model list, click Simple, and then click OK.
For Microsoft SQL Server 2005:
- Start SQL Server Management Studio, and then locate the SMS database.
- Right-click the SMS database, and then click Properties.
- In the Database Properties - DatabaseName dialog box, click Options.
- In the Recovery model list, click Simple, and then click OK.
References:
Transaction log grows unexpectedly or becomes full on SQL Server
How to stop the transaction log of a SQL Server database from growing unexpectedly
The SMS database may unexpectedly increase in size after you install SMS 2003 Service Pack 2
Reasons why you should use the Simple recovery model for the MOM 2005 OnePoint and SystemCenterReporting databases
I guess Sherry Kissinger (SMS Expert's MOF Master extraordinaire) and I are playing tag with these Remote Assistance edits! Sherry did an excellent job documenting how to inventory specific remote assistance events in her blog entry: MOF edit - Remote Assistance Requests Accepted, which was based loosely on my WQL Query edit using the View Provider example. This seems to be a hot topic lately as someone else also contacted me about the MOF edit who wanted to inventory other Remote Assistance events so I figured I'd share my results here to help out anyone else looking for this information. These edits are all based on performing simple WQL queries using the WMI View Provider.
The trick here was that there are limits to the number of WQL keywords that can be used in WQL queries using the View Provider (large numbers of WQL keywords used in a complex query can cause WMI to return the WBEM_E_QUOTA_VIOLATION error code as an HRESULT value. The limit of WQL keywords depends on how complex the query is). So I couldn't add in a bunch of OR's in there for the various events generated by Remote Assistance processes. To get around this, I just queried for all events generated by Remote Assistance (SourceName = RemoteAssistance). This was great until I discovered that the actual Remote Assistance connections do not show up in the event log with Remote Assistance as the source! Turns out, the actual connections are generated by a .dll (I think) called safrslv so I had to create a separate class for connections. Don't ask me what safrslv is or why this is different, I just take what the MOF gives me and try to make it work.
Couple of event log examples here:
On the system being remoted into:
(Remote Assistance source events):
Event 5261 : User <user> has accepted a Solicited Remote Assistance session from <IP>
Event 5262 : A Solicited Remote Assistance session for user <user> from <IP> ended.
Event 5270 : A remote assistance ticket has been created with duration: <time> for user <user>
(safrslv source events):
Event 4 : Remote assistance of <user> ended.
Event 5 : Remote assistance of <user> started
On the system that did the remoting:
Event 5023 : Expert (local user: <user>) has opened the following ticket: <ticket GUID> to the remote computer on port 3389
On to the MOF edits finally:
These edits work with SMS 2003 as well as Configuration Manager 2007 and I've actually modified the edits to account for SMS 2003 in this posting (the #pragma namespace change lines aren't needed for Configuration Manager 2007 as the data classes are in a totally separate file (Configuration.mof) from the reporting classes (SMS_def.mof)). In case you want to download the actual MOF edit (in .txt format because I can't upload MOF files!) then right-click and select Save Target As... HERE.
//Remote Assistance Requests Data Class
#pragma namespace("\\\\.\\root\\cimv2")
[Union,
ViewSources{"Select * FROM Win32_NTLogEvent WHERE LogFile='Application' AND SourceName='Remote Assistance'"},
ViewSpaces{\\\\.\\root\\cimv2},
Dynamic, Provider("MS_VIEW_INSTANCE_PROVIDER")]
Class RARequests
{
[PropertySources("LogFile"), Key] string LogFile;
[PropertySources("EventCode")] UINT16 EventCode;
[PropertySources("RecordNumber"), Key] UINT32 Recordnumber;
[PropertySources("Message")] String Message;
[PropertySources("TimeGenerated")] DateTime TimeGenerated;
};
//Remote Assistance Requests Reporting Class
#pragma namespace(\\\\.\\root\\cimv2\\sms)
[SMS_Report(TRUE),
SMS_Group_Name("Remote Assistance Requests"),
SMS_Class_ID("MICROSOFT|RARequests|1.0")]
Class RARequests: SMS_Class_Template
{
[SMS_Report(TRUE), Key] String LogFile;
[SMS_Report(TRUE), SMS_Units("DecimalString")] UINT16 EventCode;
[SMS_Report(TRUE), Key, SMS_Units("DecimalString")] UINT32 RecordNumber;
[SMS_Report(True)] String Message;
[SMS_Report(True)] DateTime TimeGenerated;
};
Resource Explorer Screen Shot:
Which gives you the resulting view in Resource Explorer (after hardware inventory has run on a system with these events anyway ):
//Remote Assistance Connections Data Class
#pragma namespace(\\\\.\\root\\cimv2)
[Union,
ViewSources{"Select * FROM Win32_NTLogEvent WHERE LogFile='Application' AND SourceName='safrslv'"},
ViewSpaces{\\\\.\\root\\cimv2},
Dynamic, Provider("MS_VIEW_INSTANCE_PROVIDER")]
Class RAConnections
{
[PropertySources("LogFile"), Key] string LogFile;
[PropertySources("EventCode")] UINT16 EventCode;
[PropertySources("RecordNumber"), Key] UINT32 Recordnumber;
[PropertySources("Message")] String Message;
[PropertySources("TimeGenerated")] DateTime TimeGenerated;
};
//Remote Assistance Connections Reporting Class
#pragma namespace(\\\\.\\root\\cimv2\\sms)
[SMS_Report(TRUE),
SMS_Group_Name("Remote Assistance Connections"),
SMS_Class_ID("MICROSOFT|RAConnections|1.0")]
Class RAConnections: SMS_Class_Template
{
[SMS_Report(TRUE), Key] String LogFile;
[SMS_Report(TRUE), SMS_Units("DecimalString")] UINT16 EventCode;
[SMS_Report(TRUE), Key, SMS_Units("DecimalString")] UINT32 RecordNumber;
[SMS_Report(True)] String Message;
[SMS_Report(True)] DateTime TimeGenerated;
};
Resource Explorer Screen Shot:
Which gives you the resulting view in Resource Explorer (after hardware inventory has run on a system with these events anyway ):
OK so here's the SQL Server 2000 inventory MOF edit. It's not as pretty as the SQL 2005 one, but it gets the job done. I honestly don't remember if the display name registry key for SQL Server 2000 shows the installation edition if it's not Standard Edition (this display name only shows SQL Server 2000 and I inventoried a SQL Server 2000 Standard installation here).
These edits work with SMS 2003 as well as Configuration Manager 2007 and I've actually modified the edits to account for SMS 2003 in this posting (the #pragma namespace change lines aren't needed for Configuration Manager 2007 as the data classes are in a totally separate file (Configuration.mof) from the reporting classes (SMS_def.mof)).
This inventory modification will tell you at least if a computer has the full version of SQL Server 2000 installed, just the client tools, or both.
Hope it helps,
Data Class
#pragma namespace ("\\\\.\\root\\cimv2 ")
//-----------------------------------
// Begin SQL Server 2000 Data
//-----------------------------------
[DYNPROPS]
Class SQLServer2K
{
[Key] String Component = "";
String DisplayName;
String ClientToolsVersion;
};
//Declare the instances
[DYNPROPS]
Instance of SQLServer2K
{
Component = "SQL Server Installation";
[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SQL Server\\80\\MSSQLLicenseInfo\\MSSQL8.00|DisplayName"),
Dynamic, Provider("RegPropProv")] DisplayName;
};
[DYNPROPS]
Instance of SQLServer2K
{
Component = "SQL Server Client Tools Version";
[PropertyContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SQL Server\\80\\Tools\\ClientSetup\\CurrentVersion|CurrentVersion"),
Dynamic, Provider("RegPropProv")] ClientToolsVersion;
};
Reporting Class
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
//-------------------------------------
// Begin SQL 2000 Reporting Class
//-------------------------------------
[SMS_Report (TRUE),
SMS_Group_Name ("SQL Server 2000"),
SMS_Class_ID ("MICROSOFT|SQLServer2K|1.0")]
Class SQLServer2K : SMS_Class_Template
{
[SMS_Report (TRUE),Key] String Component;
[SMS_Report (TRUE)] String DisplayName;
[SMS_Report (TRUE)] String ClientToolsVersion;
};
Resource Explorer screen shot:
You can get this MOF edit (as a .txt file) by right clicking HERE and selecting Save As...
I've been meaning to blog this for quite some time, and today I finally found some time to do it...at least partially. I made some MOF edits for MMS 2007 to demonstrate how to query for installed SQL Server 2000 and SQL Server 2005 installations using Configuration Manager hardware inventory. These edits work with SMS 2003 as well and I've actually modified the edits to account for SMS 2003 in this posting (the #pragma namespace change lines aren't needed for Configuration Manager 2007 as the data classes are in a totally separate file (Configuration.mof) from the reporting classes (SMS_def.mof)).
Below are the MOF edits for querying SQL Server 2005 installed components and instances. I've also posted some Resource Explorer screen shots so you can see what it looks like after the data is inventoried on a machine. I'll post the edits for inventorying SQL 2000 soon as well. I have to dig them up, but I think SQL 2000 MOF edits actually gave the version (Enterprise, Standard, etc…) as well.
These MOF edits are useful to determine who has a full version of SQL 2005 installed (and how many instances) versus just the admin tools at least. Anyway, below are the mof edits:
Data Class
#pragma namespace ("\\\\.\\root\\cimv2")
//--------------------------------------------------------------------------
// Begin SQL 2005 Installed Components Data Class
//--------------------------------------------------------------------------
[dynamic, provider("RegProv"),
ClassContext("local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SQL Server\\90\\Uninstall Info")]
Class InstalledSQLComponents
{
[Key] String Component;
[PropertyContext("Product")] String Product;
};
Reporting Classes
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
//---------------------------------------------------------------------------------
// Begin SQL 2005 Installed Components Reporting Class
//---------------------------------------------------------------------------------
[SMS_Report(TRUE),
SMS_Group_Name("SQL Server Installed Components"),
SMS_Class_ID("MICROSOFT|Installed_SQL_Components|1.0") ]
Class InstalledSQLComponents
{
[SMS_Report(TRUE),Key] string Component;
[SMS_Report(TRUE)] String Product;
};
//----------------------------------------------------------------
// Begin SQL 2005 Instances Reporting Class
//----------------------------------------------------------------
[SMS_Report (TRUE),
SMS_Group_Name ("SQL Server Installed Instances"),
Namespace ("root\\\\Microsoft\\\\SqlServer\\\\ComputerManagement"),
SMS_Class_ID ("MICROSOFT|SQL_Instances|1.0") ]
Class ServerSettings : SMS_Class_Template
{
[SMS_Report (TRUE),Key] string InstanceName;
};
Resource Explorer screen shots:
You can get this MOF edit (as a .txt file) by right clicking HERE and selecting Save As...