philipnet

Sort of.

As you may (or may not) know, I live and work in the UK. In my previous job I worked with SMS and I still keep in touch with the online community I discovered. And it's through that community that I found this: http://spaces.msn.com/members/alfred/Blog/cns!1peScUDIRoEIsu-1YenjVb8w!301.entry .

At the end of September, Microsoft will putting on a "The Best of MMS" at their Reading campus, near where I live. It's a one-day event with what looks like to be some overview sessions of what SMS and MOM are capable of. I've already signed myself up for it and you can do the same here: https://msevents-eu.microsoft.com/cui/EventDetail.aspx?culture=en-GB&eventid=118761227 .

Something that I’ve talked about before is the similarity and the annoyances in the SQL tables and field names using in Queries and Web Reports.

Way back in October last year I saw some similarities and I wanted to investigate them further.

It wasn’t until February this year that a posting on the MSSMS list prompted me to have a look at the SQL table side of things and I confirmed my suspicions. This is what I posted to the list:

Firstly, as I've suspected for sometime, but haven't got round to fully investigating it, there seems to be a strong correlation between the table names available for reports and the sections available for reports.

I've just visually identified something. Try changing all instances of SMS_R_ to v_R_ , SMS_G_ to v_GS_ and that should get you looking at/pointing to the right tables.

Then you're going to have to change some of the field names: Some of the text fields may just need an '0' at the end. Some of the others require a bit of lateral thinking - i.e. it's not SMS_R_System.LastLogonUserName but v_R_System.User_Name0 .

It seems that it’s a good few of us who are interested in this aspect of SMS. Only recently did another poster email the MSSMS list wanting to know how to convert an SMS Query into a SMS Web Report. I posted the above and her reply was as follows:

I've done what you suggest and it does work. You just have to change the table names to the correct names and the field names to the correct names, but it's a long, manual process to match the two up (query field name and report field name, that is...).

I believe all fields in one table in the query are also in one table in the report. For instance, if the SMS_R_System table has 17 fields, the corresponding v_R_System will have the same 17 fields, even if they are named a bit differently. I don't think I've run across anything yet where I found a field in SMS_R_System that was not in the corresponding v_R_System, but in v_R_Something_Else.

So there you go. Investigate everything in SMS, because you never know who else might be thinking along the same lines  .

I’ve been working on packaging a few work related software packages recently (more on those trials later). But I’ve just had a thought that wouldn’t it be nice if one could create administrative installation points for MSI files at a click of a button, rather than resorting to the command line or Start —> Run.

Well now you can.

Announcing “Create AIP” (I have a knack for stating the obvious) which is a registry file which you run on your system. It adds an entry for MSI files so you can right click on one, choose “Create AIP” then the MSI will launch and let you specify where to create the administrative installation point  .

There are two registry files, the right one depends on which OS you are running. If you are running Windows 2000 then download Create MSI AIP 2000. If you are running Windows XP or Server 2003 then download Create MSI AIP XP2003.

The difference is due the name of the Windows installation folder. With 2000 it’s “WinNT” and with XP and later it’s “Windows”.  I would have used “%windir%” and just produced one registry file, but that resulted in “Access denied” messages when invoked  .

N.B. This only works if the MSI file supports administrative installation points in the first place. Quick tests reveal that the MSI for Paint Shop Pro 7 does, but the one for the Microsoft Baseline Security Analyser does not.

This is something I often want to do. Whilst it’s great being able to see the results for all systems, but when it comes to putting my point across to management about a particular group of machines you want a report to match. 

To that end here is quick How To on how to take a SQL web report and limit it to a collection whilst utilising user friendly collection names :-) .

• Join in the table of SMS Collections which is called v_FullCollectionMembership:
  join v_FullCollectionMembership fcm on <table name>.ResourceID=fcm.ResourceID
• And then the key bit, which is to limit the results return to the specified collection:
  AND fcm.CollectionID = (Select C.CollectionID from v_Collection C where C.Name = @col)
• Lastly, you need to add a prompt that allows the user to specify what collection they are interested in:
  Name: col
  Prompt text: Collection
  Allow an empty value: <unticked>
  Provide a SQL statement:
  begin
   if (@__filterwildcard = '')
    select Name from v_Collection order by Name
   else
    select Name from v_Collection
    WHERE Name like @__filterwildcard
    order by Name
  end

  All being OK you will then be able to limit any reports to a specified collection. But don’t forget to to change the variables and table aliases as required.

  Happy reporting!

I’ve finally got a couple of systems up and running which allow me to try out Active Directory (2003) and SMS 2003 from scratch.

Firstly, you need to ensure that you have installed all the appropriate windows components in order for SMS to fully function. What you want is all hidden inside the “Application Server” section. Go into IIS and ensure BITS is enabled, and then into WWW Service and enable ASP, WebDAV and WWW Service.
If you’re going to install AdminStudio, find your way back to “Application Server” and enable ASP.NET .

Then when you get around to installing SMS, do ensure that you are a member of Domain Admins, or else you will have to extend the schema by running extadsch. And then you have to create the System Management container in AD. There are more details on what how to do this in the Active Directory Schema Modification and Publishing for Systems Management Server 2003 white paper.

I’m not quite sure what got the IP address of my AD server – it was either Network Discovery or AD System Discovery. But, as recommended, I set a subnet for the AD site in AD Site and Services —> Sites —> Subnets.

Ah, I found that I had set the site boundaries to be an IP address range. I’ve just changed to use AD rather than IP, so it should start ignoring the Linux boxes .

Continuing on with my software distribution escapades, I tried rolling out the Browse Control client to a classroom full of PCs.

Having done it manually twice already I didn’t fancy doing it again. And besides, as we have a site licence for it, it is going to be pushed to all the classrooms and I would like to see if I can get SMS to start doing some of the leg work  .

So, to that end, I copied the client setup program into a folder on our SMS server, modified the configuration to point to the appropriate teacher machine, packaged it up, distributed it and advertised it.

And so I opened up the Status Message Viewer for the appropriate advert and watched the systems all get the advert. This was about 14:30. Several hours later the package had not been run on the systems and I was getting concerned. I can’t remember exactly what I did – I’m positive that I just re-advertised the program – but I when I arrived this morning the Status Message Viewer was showing that all the clients had installed the program sometime after 17:00 yesterday.

Now to package up the Console .

Well, this week I took the plunge and tried to distribute the MSI of Firefox I had previously created.

Firstly I checked out the ever useful MyITForms and found an article on Distributing MSI Applications with SMS which started me off on the right track. I could then combined that with pages 440–445 and 449–459 of Systems Management Server 2003 Administrator's Companion. Now some of that section isn’t appropriate to distributing MSI files, but it’s worth glancing over – the first time I didn’t read all the way to p.459 so I missed the Windows Installer tab bit!

So far I’ve done the process a couple of times since with various degrees of success. Here are my handy hints for distributing MSI files:

• Run the SMS Administrators console from the same machine where the package is going to be sourced from. It makes it a lot easier if you can work with local paths and the Console will help you by putting you in the right folder when appropriate.
• You need to create an Administrative Installation of the MSI file, so run
    msiexec /a <full path of msi file>
  and it will pop up a GUI frontend to storing it somewhere.
• SMS 2003 (with SP1?) allows folders to be created in Packages and Advertisements, so use them to structure your software deployment packages.
• When creating the program don’t forget to import the MSI file into the Windows Installer tab.
  (N.B. You can import multiple MSI files per package – but only one file instance of a file per package)
• You can easily uninstall MSIs as well as install them – so why not create an uninstall program?
  (BTW, it’s
    msiexec /i <full path of msi file> /q
  for a quite installation and
    msiexec /x <full path of msi file> /q
  for a quiet uninstallation).
• After creating the programs don’t forget to distribute the programs to the distribution points.
  If you do forget, then re-advertise the program after distribution has completed.
• Organise and name the adverts the same as the package you’ve just created – it makes it a lot easier to keep track of what advert is for which package this way.
• Where I work we generally have installation programs run when users aren’t logged in. I therefore set the program to download and then run, rather than have (loads of) clients all hit our network bandwidth for the brief few minutes between class changes.
• On that note, do set the Legacy Client Software Installation Account (Component Configuration —> Software Distribution Properties). Just ignore the “Legacy Client” bit in the text – you need that account set if you want to install software without any users logged on!

Just wondering if anyone was going to the SMS Alliance briefing at Reading/Thames Valley Park on Feb 8th: http://www.sms-alliance.com/flash/events.html ?

I'm kind-of curious to know who else is/might be going as well as what to expect.
I don't have any control over any budget, but I guess it might be useful to come away with a few ideas.

If anyone can come up with a way to justify this to management, that would be useful as well, otherwise I'll have the day off as holiday.