Linking systems to Advertisements for user notifications


The SMS 2003 web reports have some cool built in stuff around advertisements, one in particular is viewing advertisements for a specific system. A way that you can take advantage of this is to include a link in your customer communication so that they can view all active advertisements hitting their system. But how do you do this without giving them instructions for navigating throughout the web reports? Wouldn’t a link be nice?


The actual link is going to http://REPORTINGPOINT/smsreporting_SITECODE/Report.asp?ReportID=131&ComputerName=COMPUTERNAME (Note this is not a real link as everything in CAPS needs to be changed for your environment). The beginning of this link is easy enough to change as your SMS Reporting Point URL won’t change that often, but now what you need is some custom scripting to grab the COMPUTERNAME dynamically when someone visits the webpage.


To do this first you will need to enable ReverseDNS Lookups on your web server. You can do this by running the following command as documented in KB245574


cscript adsutil.vbs set /w3svc/1/ROOT/EnableReverseDNS “TRUE”


Once this has been done, copy the text below into a file and call it adverts.asp:


 


<%


Dim strUser


strCompName = Request.ServerVariables(“REMOTE_HOST”)


strPullDNS = InStr(1,strCompName,”.”) -1


strCompName = Left(strCompName, strPullDNS)


Response.Redirect “http://REPORTINGPOINT/smsreporting_SITECODE/Report.asp?ReportID=131&ComputerName=” & strCompName


%>


Edit this with notepad and change the REPORTINGPOINT and SITECODE values to accurately represent your site configuration.  Then go to the <DRIVELETTER>:\Inetpub\wwwroot\Smsreporting_SITECODE directory on your reporting point and place the adverts.asp file in it. After this you can simply run the following from a web browser to automatically detect the system name and display all active advertisements going to it:


http://REPORTINGPOINT/smsreporting_SITECODE/adverts.asp


 


***Remember to back this up because whenever you run a site reset or upgrade (like SMS SP1) this could be overwritten or deleted!

Quick Tip: Using -Any- for your Software Meetering rule

Sorry things have been quiet here of late but I’ve been doing some traveling for work recently and there has been a lot going on away from the keyboard taking up my time as well but I hope to get back to giving more SMS-nugget related posts here. One thing that I’ve really been getting into recently is Software Metering and have found that most of my customer’s mission critical applications don’t have information such as the language or version in the file header which I’m looking for. Its way up in the list (above ‘Afrikaans’) but you can specify -Any- as the language if you have a rule in place but aren’t seeing the results you thought you might. Even if you are using a wildcard for the file version many times this adjustment is needed for the Language as well.

AdminStudio SMS Edition?

A while back we had a lively debate on SMS Packaging tools. In that time Microsoft has worked with InstallSheild to offer AdminStudio SMS Edition because of the need mainly for people to edit MSI files and customize them for deployments. This tool by no means eliminates the need for SMS Installer since you can’t do any custom scripting, etc, without purchasing the full AdminStudio. The documentation is also pretty weak IMHO which I’m not sure if that falls on the shoulders of Microsoft or InstallSheild to offer more public guides for this. Either way I recommend everyone to download this and at least try it out so that you can compare it to whatever tools you currently use today and decide if it would be useful as a standard part of your organization’s toolset. After doing that go ahead and vote in the poll we have below because this information will be viewed by Microsoft as feedback on AdminStudio SMS Edition and what direction they should take going forward.


Poll: http://myitforum.techtarget.com/forums/tm.asp?track=NL-390&ad=494296&m=81623

What SMS shops need to know about October’s bulletins and the MS04-028 Scan Tool

Along with this month’s Security Updates, Microsoft has also released utilities for SMS and non-SMS environments to Scan and Patch their systems for MS04-028. You can find them here:


 


KB 885920 – How to obtain and use the MS04-028 Enterprise Update Scanning Tool in environments that use Systems Management Server


http://support.microsoft.com/default.aspx?scid=KB;EN-US;885920 – Will be available by noon PDT Tuesday


Public download location (Available by noon PDT)


http://www.microsoft.com/downloads/details.aspx?FamilyId=C4745685-9521-4B63-A338-0B3E2DCBF2BB&displaylang=en


KB 886988 How to obtain and use the MS04-028 Enterprise Update Scanning Tool in environments that do not use Systems Management Server


http://support.microsoft.com/default.aspx?scid=KB;EN-US;886988 – Will be available by noon PDT Tuesday


Public download location (Available by noon PDT)


http://www.microsoft.com/downloads/details.aspx?FamilyId=70E1C04D-47E2-4EA6-A638-11AB6AD9BD6E&displaylang=en


 


There are a few things to know about this as well as this month’s security bulletins.


1. This MS04-028 Scan Tool works for BOTH SMS 2.0 and SMS 2003


2. You DO NOT need to upgrade to the SMS 2003 SP1 Scan Tools to install this update.


3. MS04-038 has a caveat on IE 6.0 SP1 where the MBSA cannot detect it but READ THE BULLETIN!!!! The SMS Team created pointers in the Security Bulletin Catalog (MSSECURE.XML) for this update to run a SMS specific hotfix which supports the standard IE switches (/q:a /r:n).  This enables you to deploy this update in the same DSUW created SMS package as the other updates this month. As per the bulletin:


 


Can I use Systems Management Server (SMS) to determine if this update is required?
SMS can successfully deploy this update for all versions of Internet Explorer, except for Internet Explorer 6 SP1. As noted in the Affected Components section of this bulletin, this release includes two packages for Internet Explorer 6 SP1. One package is designed for Windows 2000, Windows XP, and Windows XPSP1. This package uses the Update.exe installation technology discussed above. The second package is designed for Windows NT, Windows 98, and Windows Me. MBSA is not able to determine which Internet Explorer 6 SP1 update is required for a specific Operating System. A package intended for SMS Deployment only has been created that contains both versions of the Internet Explorer 6 SP1 updates. When deployed with SMS, this package will detect the operating system and install the correct version of the update for that operating system. MBSA when used with SMS, will instruct SMS administrators to deploy this SMS Deployment package. For more information on this update, please see
Microsoft Knowledge Base Article 887437.


This means that all bulletins this month are SMS deployable because of the extra work ahead of time that the SMS Team put in to make this so. Great job!

Integrating your users with SMS

One aspect in deploying SMS can be to let your user base interact with the SMS environment. Many organizations don’t take advantage of a lot of the new features in SMS since older versions of the product had caveats of being site-wide settings or not working properly. Good examples of this are the Software Updates functionality of letting the user define their own schedules or using the individual program settings pop up a taskbar notification to open up Add / Remove Programs. An easy way to lower support costs in your organization is by minimizing the need for Desktop Technicians to visit desktop systems by creating standing Advertisements for applications that might be available company-wide and putting start menu links to access the SMS control panel applets easier. In SMS 2.0 you could do it easily however this process has changed a bit in SMS 2003 since you have more options. One way to do this would be to use the Rundll32.exe application as in SMS 2.0 and just use the new Run Advertised Programs applet like so:


RunDLL32.EXE shell32.dll,Control_RunDLL %WINDIR%\system32\ccm\smsrap.cpl


I don’t like this UI though, something about it just rubs me wrong. So lets see if we can do something more nice, nice:


control %WINDIR%\system32\appwiz.cpl,Add/Remove Programs,1


Much better. Now you can create a Start Menu link for your users and build process around this. Its all about education at that point. New users can be instructed to go there for reinstalling software and email communications when you want to give users the ability to run Advertisements early can include instructions pointing to these links.

Good numbers

For those that missed it, SMS 2003 SP1 has been released and its getting some pretty good reviews so far.


I decided to do a bit of comparison since this is a bit of a landmark for SMS2K3.  The real famous Service Pack for SMS 2.0 was SP2 because of all the problems it caused (cough, cough, I mean fixed).  🙂



 


 

Pretty good numbers if you ask me!

What Documentation?


I’m crazy about documentation. More than that, I’d call my self a “Documentation Guy”. Not only do I go through extra steps to document all technical and process decisions for the systems I control but I also hound the people on my team for documentation that in a round-a-bout way impacts my space. Why am I like this? A couple of reasons, some are selfish and others are not. Let me explain.


Good documentation is a crucial piece of a solid IT organization. I didn’t always believe this and would be the guy saying “Who’s going to read that?” Problem is I would move onto another project and bam, something would happen and screw up a configuration I made in the past. No one knew what I did and usually there wouldn’t be time to figure things out because of these critical business applications needing to be online. This brings me to my first point:


Point #1 – Good documentation allows those that will be maintaining your systems later on to know what you did to set them up


This is probably the biggest impact that good documentation can have on you. Wouldn’t it be terrible if you are now part of the Domain Administrators group and while on vacation you get called because SMS is down and no one knows how you set something up? Of course documentation, and more specifically detailed documentation, also gives back to the company and others knowledge that you have acquired through training and experience on the job. For any organization to progress and move forward they need to minimize the learning curve that new team members have. If processes, procedures, and technology implementations have to all be relearned whenever a new person joins a group then they will have to work just as long or longer to get to the point you are at. Which means that:


Point #2 – Good documentation helps an organization progress long after you have left


This point is largely about the long term benefit you are giving to the company however it also has a certain level of satisfaction to it. Personally I want to know that the work I did for a company was not all for nothing and lost after I left. The best thing that I can do for my legacy to be carried out is to document the thoughts and ideas that went into building infrastructures along with the technology because this ensures not only that things are done right but that the people doing them know why they are.


Point #3 – A sysadmins memory is usually lousy


We all need to reference not only what we did but also what others did later on in life when making changes or implementing either a new technology and/or process. How can we do this without documentation? Anymore its becoming a rarity when all you do is one job. Because of this everyone forgets something they did in the past especially when it comes to technical configurations. Document it well and you’ll save yourself headaches in the future.


Point #4 – You have to know what you are talking about to make good documentation


I’ve met a lot of really smart people over the years and hands down the one quality that the people I’d refer to as “guru’s” have in common is good documentation skills. They have to know what they are talking about in order to put technical thoughts down on paper. Documenting things almost always leads to a deeper understanding of a product or technology. Take your SMS infrastructure for example: If you are documenting how your site will have NLB configured as your Management Points you’ll start asking questions about how the process flow works and answer them before anyone else does. How does NLB disperse traffic between the Virtual IP and the different hosts participating? How do clients know how to go to that Virtual IP in the first place? What happens when one of the hosts goes down? Once you start asking these questions and doing the research to answer them you will be able to speak with authority on a multitude of subjects.


Point #5 – Complex systems need to often be set up in a repeatable manner


When your dealing with something as complex as Domain Administration or a Systems Management product many times you will be asked by management to roll out a new environment in a very short timetable. The thought here is you’ve set this up once already so its cake to bang out a new environment right? When doing something like this there are often dozens if not hundreds of steps involved and the fastest way to accomplish them is to follow appropriate steps in the correct order. Good documentation here will save you trial and error time by not rooting around for product or system requirements as well as other dependencies you accounted for in the past but don’t have the time or resources now to research. A perfect example of this are server builds. Even if you have an imaging process in place there are often post setup tasks that must be done to ensure that systems are configured on the network properly. How about all the IIS configuration for SMS 2003? Instead of figuring out later on why you are having some DP issues with BITS, follow your documentation on how to set this up correctly in the beginning and save yourself the headaches down the road!


 


How should people get started with documentation? I actually don’t think its always the best to start documenting policies and high-level architecture if you don’t have much experience with documentation in the first place because chances are the results will be weak. Do you help out your desktop guys a lot with troubleshooting a specific application or network problem? Try documenting what your process is to resolve it. Go DEEP into detail! Call out explicitly in your documentation who your intended audience is and give an overview of what your documentation is trying to accomplish. Always include the ability to update it later with versioning, author(s), and track changes clearly listed for others to reference in the future (please, no jokes about documentation inside of documentation). List out your steps and remember that the people following them will most likely be technicians and not Engineers or Sysads. Fear not screenshots – they are your friends! Don’t skimp out on the good stuff either such as Conclusions and where to go for help if the documentation doesn’t prove effective for everyone. And if possible always include references or links to more information to those interested.


 

Process vs. People

I heard an interesting phrase today when talking to some consultants about SMS infrastructures they had worked on.  “In company A they didn’t really have that large of a staff so we focused more on making sure the SMS infrastructure was rock solide, whereas in company B they had so many Administrators worldwide that process had to be a heavy focus more than company A just because you need to make sure that everyone is following propper procedures”.


This statement really holds true for a couple of reasons.  Start with the smaller company.  Usually its hard getting resources dedicated to SMS and when you do they are usually splitting time between other responsibilities.  It would be natural then that these Administrators don’t have time to become not only product experts for SMS but for other things impacting SMS as well such as AD maintenance, server monitoring, etc.  When an outsider is looking for areas to improve this organization then its more technical because that is an area that would be lacking and less people are doing the technical work so you don’t need to waste all that time on process when so few will be using it.


That being said, process is critical as an organization grows larger.  More importantly though process needs to mature and improve as teams grow larger to ensure that all Administrators are doing thing in a consistent and correct manner.  Take reporting for example:  Corporate headquarters institutes custom registry logging in their SMS Packages which is also rolled up into inventory.  They can then see all sorts of data – lets use image version here as well.  Well the CEO can now see all imaged systems out there and also all non-images on the network and you also correlate this into a report showing that the unlicensed software on your network is coming from the non-imaged systems.  This helps you true-up licensing and everyone is happy.  But what happens when upper management finds out that this is only for headquarters and a couple other locations?  This is where process is key, so that you could have this consistent reporting across all your sites globally and not be out of compliance.


I could go on for hours about being bitten in the past because process wasn’t developed for something I just took care of on a case-by-case basis on different servers (ahh, sms_def.mof I know you well).  The point is if you are an Administrator faced with the challenge of planning for a growing organization its best to develop and document sound processes and procedures ahead of time.  This will make things much easier on you down the road and let you focus on more important things, like surfing with Scoble 🙂


 

What is up with KB870669 and SMS?


So by now you know about the stop-gap effort by Microsoft to disable ADODB.Stream while they are making a patch to actually fix the update (yes, a patch is on the way and this isn’t private information as the press release is here). What I want to know is what team made this Hotfix installer?


There has been so much effort over the past year by all teams within Microsoft to have standards with Hotfixes and this one follows none. The registry logging isn’t even in traditional places to track if the Hotfix has been applied which is really lousy for SMS Administrators because now you have to do some manual modifications to your SMS_DEF.MOF if you want to track the deployment of this in your enterprise. Nope, you wont get this detected by the Software Updates features of 2.0 or 2K3 either as this is considered a “Critical” update and not a “Security” update so the MBSA won’t pick it up.


Ok, I’ll buy all that. I’m sure internal policy and process dictates what can or can’t be done. But why isn’t anything mentioned in the KB article about this for SMS Administrators? Shouldn’t there be something in the KB even to at least link to http://www.microsoft.com/technet/prodtechnol/sms/sms2003/patchupdate.mspx for Administrators who don’t know this information to follow?