SMS 2003 good vs bad

[matrixnz]

Hi

We are currently migrating to Windows 2003 from Netware, in the process we are setting up SMS 2003, which I will be administering. However I'm not sold on SMS 2003 and have my reservations, I suppose I keep comparing it to Novells Zenworks, SMS offers alot, but to me it just seems it does it half cocked. For eg. we believe there are 5 reasons why we need SMS.

1. Software Metering
2. Software Deployment
3. Windows Updates
4. Software/Hardware Inventory
5. Desktop Deployment

1. From what I've seen, read, software metering is non-existant, i.e. it reads usage, exactly how Add/Remove programs reads usage and we know how reliable that is.

2. Software Deployment seems to work fine, basically it installs software as a System Admin on the machine, using advertising etc.. seems a little annoying to setup, like the advertisement, program, package etc.., especially since we won't be using distribution points rather dfs shares.

3. Windows Updates, because of the up and coming WUS our Network Architecture recommended that we stay with SUS/WUS as it's easier to approve, clients can be controlled via GPO, Windows Update uses the same method as Software Deployment i.e. advertisement, program, pagage etc...

4. Software/Hardware Inventory, it looks good but it just seems to use WMI to get all it's information like any other type product, I was hoping with software you could filter existing exe, coms etc.. like cmd.exe or command.com but it doesn't, from my understanding you have to write a SQLWMI query, its called something else but it's slipped my mind.

Lastly

5. Desktop Deployment, using OS Deployment Feature pack, because in the past I create our companies images using Ghost, I was hoping this would be similar, but it seems to lack a number of features, firstly you require network access for it to work, you need to either be connected to the domain or have access to SMS before deployment will proceed. If it's a brand new machine you need to boot from a custom Windows PE Boot CD, images are unicast not multicast, which means x more bandwidth for each machine. Images can't be used to reimage a standalone machine.

Since we are still in the first stages I'm wandering with all it's limitations if we should still go ahead with it. Does anyone have any thoughts, or ideas, experience, if you believe I'm wrong can you please say in which areas.

Thanks for your time.

 

[globalstrata]

Software Metering - as I understand, SMS installs a monitoring component on each client in order to perform the usage monitoring.

Software Deployment - the advertisement of a package is a bit of work to setup but mainly to try to give you flexibility. What I have liked about this is the capability of writing your own scripts and SQL queries in order to further customize the installation requirements. However, this would mean that you would have to know some about SQL queries and VBScript.

Windows Updates in the SMS site is still have lots of work to be done. There is no just one scanner that checks for all the updates so you have to setup multiple advertisements to get the patches installed. And even that, does not install every patch available. The problem about SUS/WUS/US is that there is not much reporting available at least at this time.

Software/Hardware Inventory definitely uses WMI. Actually, in my experience, most of the problems that workstations encounter are due to WMI or DCOM problems.

About Desktop Deployment, you are right about that one. That is why I have not used this feature much.

Most of the companies that I have consulted for have Microsoft Enterprise License Agreement, so it turns to be cheaper to deploy an SMS solution than going with another solution. In addition, because of how it interfaces with Active Directory and MOM, there is a lot of features that you are not available anywhere else.


Gladys Rodriguez
GlobalStrata Solutions

http://www.globalstrata.com

 

[matrixnz]

Hi Gladys

Thanks for your input.

"Software Metering - as I understand, SMS installs a monitoring component on each client in order to perform the usage monitoring."

You're right there, it seems you set Software Metering Rules and than select the executable you wish to meter, however, during my SMS 2003 training our tutor lead us to believe that the information was similar to add/remove programs usage report, i.e. was inconsistant with actual usage.

"Most of the companies that I have consulted for have Microsoft Enterprise License Agreement, so it turns to be cheaper to deploy an SMS solution than going with another solution. In addition, because of how it interfaces with Active Directory and MOM, there is a lot of features that you are not available anywhere else. "

You're correct there also, we chose SMS because of our MS Enterprise License Agreement, being a cheaper alternative to Altiris or other such products. Although SMS claims to be integrated with AD, it seems to be a product on it's own, i.e. it's not controlled by AD and AD isn't controlled by SMS. GPOs also seem to be non existant for it, I also found that using collections rather than existing AD groups to be annoying, although using the hardware inventory to specify software deployment is great idea as a whole, however for us, 95% of our machines are P4 with 1GB memory so isn't really applicable to us. I'm not to sure about MOM we aren't implementing this at present.

Thanks again for your insight, it's been very helpful, I can see that this is going to be a difficult decision to make, use only 1 or 2 out of the 5 reasons, is it worth it? Cost wise it seems the better way in the short term anyway, long term not so sure, if results are inconsistant, could cause problems, I suppose it can only get better

Cheers

Cheers

 

[tbrennans]

Like anything there are good and bad points, overall having used SMS from the 1.0 days they have come a long way.

1: I agree with your eval. the software metering has changed since 2.0 and now it is more of an inventory based software metering. Software metering doesnt actually add anything over and above what the sms client install, installs, it just uses it. All the client options install on setup but they arent utilized until you push down a client policy telling the client to use it IE: software inventory, hardware inventory ect..

2: DP's are very practicle when used properly. If you have no slow links or wan connections, your fine with a share, however if you want to use bits or have clients over a slowlink/wan you dont want to saturate you'll want to use DP's. Also you can control the download location to the clients with PDP's so they just wont load from anywhere. DP's are another part of granular control of SMS

3: Once again its the granular control you get with the SUS feature of sms2003 as apposed to WUS (they are changing the name in the next month or so) With that said MS themselves use WUS to push out patches to their clients (although they have no legacy clients to speak of which WUS wont work on)after they push with wus SMS goes through and installs the patches WUS missed. The one thing bad with WUS for me was the shotgun blast approach, I like more logging and and control.


4: you can filter by manufacturer name, and as you said you'll need to get into scripting to really break info down

I havent played with the OS deployment tool yet so *shrug*

 

[globalstrata]

Another plus for SMS is the fact that it uses SQL as backend and one can write scripts to extend its capabilities in order to automate other processes and create the required reporting. I suggest you to go to the following links in order to see all the free tools available.

http://www.microsoft.com/smserver/downloads/2003/default.asp

- Download the SMS Toolkits. The MP Troubleshooter is a tool that checks whether the servers have the pre and post requirements to be SMS Management Points.

http://myitforum.techtarget.com

- On this website, search for Downloads as well as MOF, MIF and scripts and you will see all the already built queries, reports and small tools available to extend the capability of SMS.


On thing I have to tell you, SMS installation and configuration should be planned correctly and documented, because SMS problems can be time consuming to troubleshoot if you do not know all the INs and OUTs of SMS. Microsoft even has some troubleshooting flowcharts available to help:

http://www.microsoft.com/downloads/...83-D789-40DB-9B06-3E0D5916EF51&displaylang=en

However, even that, it is time consuming because you have to look at the clients logs (\\client\admin$\system32\ccm\logs), the SMS Server logs, check that all the Active Directory and SQL Registration is correct and that the correct services are in place. Look at these two articles. These are the most common problems that I have encountered with some of my customers:

http://support.microsoft.com/?kbid=832109

http://support.microsoft.com/?kbid=829868

thread22-1026289

Good Luck,



Gladys Rodriguez
GlobalStrata Solutions

http://www.globalstrata.com