philipnet

The fun and games continue with our freshly re-setup SMS server.

To refresh your memory, I uninstalled and then re-installed SMS 2003. I left the clients alone and, obviously, they continued doing what clients do. Well it turns out that one thing they do is tell SMS about any changes in installed software. Interestingly, it appears that the SMS clients generate a 'no change' message - I guess that's just how the Data Discovery Manager works ;-) .

Last week, whilst I was trying to get the clients to be assigned to a site I had the Data Discovery Manager running (it appears to be controlled by the Software Inventory Client Agent). This generated a lot of warning log messages mentioning orphan files, that DDM wasn't running and various records not being found (Message IDs 3701 and 3707). The last part made sense - with a freshly re-installed server of course the records weren't going to be there!

To stop the log messages I disabled the SICA and stopped the DDM. I then, as previously mentioned, found the speediest way to get SMS to re-assign a site to all our machines and then re-enabled SICA and DDM.

Then I started getting something more positive out of SMS. It then stated telling me that ""because an attempt was made to update inventory information"" a resynchronization of a particular machine was requested (Message ID 3703). Lo and behold SMS started resynchronizing machines and I'm now getting inventory information being put into SMS .

I finally got to grips with JOIN last week!

Not that I've spent a long time trying, you understand - just that I needed to modify a report and that required me to delve into the depths of my SQL knowledge and to google and bit. I probably need to go over my SQL/database notes again!

But what gets me with Queries and Reports is the different table and field names! One can't cut-n-paste straight between the two. At the moment I'm resorting to modifying existing reports to do what I want. But I think it may be possible to convert the names - watch this space!

It seems that site assignment and network discovery go hand in hand.
Or at least that's what some rough tests show.

In my bid to re-setup our (new) SMS server on a site which already has the SMS client in most existing PCs and on every new or re-setup PC (as it's on our image) I've had the luxury of some knowledge and a little bit of time. Conversely when I/we/us setup up our test SMS server before we hardly new anything, but had loads of time to get it right .

First of all I setup the site boundaries. I thought that if I just limited it to Active Directory and just did an Active Directory discovery then everything would be sorted and SMS wouldn't do it's impression of DoS-ing the network . I was wrong. I had to have IP address ranges included in the boundary or else the SMS server wouldn't include itself in the site.

Secondly I had to turn on network discovery in order for SMS to assign site codes to all our machines (and we only have one site).

That was yesterday and now about 60% of the machines have been assigned to a site. The remainder were most likely turned off last night when the network discovery was run.

So I'm off now to configure our SMS server to DoS the network once a week.
It's not as if people are complaining that our network's slow enough already .

I'll eventually get round to saying why I decided to do this, but for those who have to or decide to do this, either reboot the machine in-between or boot into safe mode (no networking) and then reboot into normal mode at the earliest opportunity.

The reason?
SMS creates several services that run in the background. When you uninstall SMS it marks these services for deletion, but they don't get deleted until after a reboot. Consequently, when you re-install SMS it will try to install all these services again – but it can’t as they are already marked for deletion! From what I can tell, with a normal boot SMS starts early enough to stop the uninstallation of the previous services but this isn't the case in safe mode.

I haven't experimented with fiddling around with the SMS services after uninstallation. You could always give it a try  .

In the spirit of create, share and consume I've created this posting to share some blogs with you that you can consume ;-) .

Okay, here’s a useful management software blog: http://blogs.msdn.com/managementupdates/category/5152.aspx

And there appears to be a few of the SMS (and MOM) developers with blogs as well:
Check out Johnathan Hardwick’s blog: http://blogs.msdn.com/jonathanh/ who has SMS and SMS & MOM sub-blogs, SMSPerfGuy: http://blogs.msdn.com/smsperfguy/ and Tjlau: http://blogs.msdn.com/tjlau/

All this has wetted my appetite for SMS. Unfortunately over last several months I have been unable to work with it. This week I hope to digest some of what's new with SP1, re-build our SMS server (I'll explain later) and get to use it!.

Hi Steve,

Just a comment on a couple of your points:

- mis-information on the primary admin console
Yep. I've seen this as well. I've had it both ways with SMS saying a machine has the client when it hasn't, and that it doesn't have the client when it has.
I put the later down to there being some sort of delay or lag between the client and the database on the server and the former down to machines being re-imaged. This was a problem last academic year (2003/2004) as our image didn't have the SMS client on it, but our current one does. Rather handy when you need to do the odd thing or two to finish setting up a machine!

- blank SMS client site code
Yep, we've had this one as well. Our work around was to specify the site code during client installation so I can't offer any help. Amusingly it has been mentioned that we do split our SMS setup into multiple sites. So heaven help us when it comes to updating site codes!

Yes, SMS2003 has been pretty good at client deployment (except for one classroom last year that never got it!). And trust me, you will need all your energies to get patch management/roll out working!