A few weeks ago I was doing Q&A at the SMS booth with some Microsoft employees at TechEd and a woman approached us about the best way to roll out a particular piece of software. If I remember correctly, she currently uses InstallSheild to call the vendor's silent installation routine but her question was in regards to the package reporting fields within the SMS Administrator's console. After she walked away the comment was made to me "People still package software before rolling it out, huh?".

WOW. I was blown away that there are people inside the SMS Product group don't really think that packaging isn't a major piece of a solid SMS Infrastructure. I'd actually go out on a limb and say it's one of the most critical pieces of a good SMS implementation. This made me do a little research into some of the documentation that’s out there for SMS2K3 to find some information on software packaging. Low and behold there really isn't much out there. In fact this is pretty much all there is:

You can use SMS Installer to create an executable file that you can add to a package and advertise to clients. SMS Installer creates a self-extracting file or Windows Installer file that includes the data and files for the software application and the installation script that you created using SMS Installer. By using the SMS Installer Script Editor, you can modify the installation script that SMS Installer creates.

SMS Installer does not create the package, distribution points, or advertisements within SMS, so you must use another method to perform these tasks. SMS Installer creates a package definition file that can be imported into SMS with either the Distribute Software Wizard or the Create Package from Definition Wizard. For more information about SMS Installer, see Chapter 7, "Creating Software Installation Packages with SMS Installer."

Really when I think back at all the Microsoft demo's and conference sessions you almost always see them call an ISV's silent installation directly in the program command line or an MSI. Now I know that there are many people within the SMS Product group that don't think app's should be deployed like this. In fact I was even talking with one of them (names not divulged to protect the innocent!) when I was in Redmond and he went on for about 20 minutes at lunch telling me about one customer that started taking people with high levels of software development in their backgrounds and made them packagers for SMS. When this started happening the quality of packages and success rates of deployments went up by a dramatic level. Why is this? IMHO for a couple of reasons:

1. Developers are usually more detail orientated. They make sure that a package is fully tested across all platforms and all bugs are worked out before deployment in the same manner that they would test a new product that they developed before selling it to a customer.

2. Developers account for unknown variables in the environment. Just sending out a package isn't enough as you need to think about what might cause your installation to fail as well as fallback on experience of things you know have impacted your installations in the past.

There are also other factors which tell me not everyone believes software packaging is dead. Take a look at the SMS2K3 SDK. If the SMS Product group didn't think that packaging was still important why would they create functions like InstallStatusMIF?

And what about the line of business applications that don't support silent installation parameters? Smaller organizations with budget constraints are stuck with using SMS Installer for repackaging which, lets face it, is getting to be an antiquated tool that hasn't been updated in quite some time. They don't have the resources to put towards an enterprise packaging toolset like Wise or InstallSheild in order to do quality deployments.

So what needs to change? I think its Microsoft's perception of the SMS Administrator to be perfectly honest, as it is the SMS Admin's toolsets have needed to grow for SMS 2003. The days of the 2.0 Admin are gone with just needing SMS and some domain knowledge. SMS 2003 ties in more closely with AD for one so knowledge of LDAP communication with the directory, etc is needed (and don't even get me started on the amount of time people spend troubleshooting MP communication issues because of SPN registration issues or Computer access/authentication problems) as well as IIS configuration and so forth. Its really funny when I see a vendor at a trade show talking about how their management technology can solve all of your problems because they have all these built in reports, etc, so you won't need to waste time on that stuff. No way any ISV can do that. The purpose of reporting is so it can be customized for your organization so the knowledge to do that stuff has to be in-house, especially with really large organizations. The same thing goes for Software Packaging. Really good packaging teams have reporting built into their installers to make troubleshooting easy and reporting integrated into your SMS site. Some common things done to improve software packages are:

- Standard package logging location with easy to follow flow and error messages

- Registry reporting for inventorying

- Custom SMS Status Messages

- Package Versioning for tracking of bugs

- Anti-Virus Software stopped before installation and restarted after (a common recommendation from ISV's)

- Checking for backups (in the case of major updates like Service Packs)

Most importantly however is the ability to include checks in your scripts for problems. An example would be a problem I ran into with SP4 for Win2K. We had this application called Win Driver which placed a library, Windrvr.sys I believe, in the %sys32%\Drivers directory. Turns out that on every system if it wasn't at the latest version the system would blue screen. Now, if you have 200+ machines that this application is on that could be an issue. So what does a good software packager do here? He (or she) can check to make sure that the file version of Windrvr.sys is recent enough and if its not either abort the installation (and use the good packaging practices above to log this efficiently and report back to SMS) or automatically update the file if its not in use and continue with the SP4 installation.

That’s just one of many examples that can be done through good packaging which is really one of the most lucrative pieces of SMS where effective enterprise management can be seen. Its just a shame that Microsoft won't be providing the tools to do this in the foreseeable future so we are stuck with limited functionality or the purchase of high-end (read: expensive) tools to get the job done. Additionally these 3rd party tools have no impact into the future versions of SMS and integration into the management structure. Yeah, many are gold level partners but lets not kid ourselves here - Microsoft has the biggest impact on Microsoft so if you want to see some cool integration with a software packaging tool they most likely need to be doing it. Why not SMS Installer 3.0 with some new actions like:

- Add new Advanced Client Policy

- Compile data class to WMI (yes! No need to copy your custom sms_def.mof to the client and compile)

- Initiate HINV/SINV

- Initiate Machine Policy Retrieval Cycle

- Update Get System Information to get the SMS Site, Default MP, AD site, etc

Back from vacation now - sorry its been quiet here for a couple weeks. I actually split my time between relatives visiting in town and helping out the SMS Product group by manning the SMS booth at TechEd last week (oh yeah and a 1 night trip to Vegas). What an interesting experience at TechEd! My name tag actually listed that I worked for Microsoft along with having to wear one of the traditional geeky blue shirts so everyone thought I worked for Microsoft :) Its really interesting seeing how fast people do a flip-flop when talking to you and they find out you aren't a Microsoft employee - for whatever reason its like you get more credibility because they don't think you are another member of the Borg. I also had people coming up to me left and right just to vent about a failed SMS 2.0 implementation or go on about some struggles they were having with their SMS2K3 deployment. Many complaints were just about political issues within their organizations and not technical at all. I think it just says that people like to talk to others about their problems and get things off their chests. What I got a kick out of the most were people that came up to me saying "you're probably just a salesperson that doesn't know a deep technical answer to my question, but let me ask it anyway" and then I'd actually give them a deep technical answer back and watch their eyes glaze over. It was a lot of fun though hearing some real-life issues that people had and working to give them ideas for resolution. The face-to-face stuff like that is a lot of fun because you get past the awkwardness that sometimes happens in email or public forums.

Overall I'd have to say that SMS2K3 has a really good name right now - much better than 2.0 ever did. I even had one guy give me a success story about his 20K client infrastructure upgrade from 2.0 to 2K3 in one weekend without any issue. A lot of organizations are also making the move from a competing management product such as Tivoli, Altiris, etc. Even more interesting was hearing that some people were rolling out SMS2K3 just for the servers they manage and letting the desktop team use another product for workstations. Now that’s a change in mentality!

MOM was generating an insane amount of buzz at TechEd as well. There were times when 10-20 people were waiting in line at the product booth to get a question answered from the MOM team (actually questions and interest in the product, not just to get Zoo tickets). This is another example of how seriously Management technologies are being taken today in companies of all sizes. Administrators seem to be realizing how these products tie into the general direction of IT today: Lifecycle Management, Security and Patch Management, etc. So what does this mean? A lot if you have expertise in the area. I foresee a big need for knowledgeable professionals in the field of Management going forward. Not only will you see a need to debunk a lot of bad information that will be out there by overnight experts but more theory, process, and techniques will need to be developed in order to adapt to all those companies out there that will be embracing SMS, MOM, and the like going forward. For me its looking like an exciting time going forward.

Fasten your seatbelts folks - hopefully the ride isn't too bumpy!