SMS packages AFTER deployment

myITforum.com Community Forum

Home Forums Blogs Live Support chat Search Articles Wiki FAQ Email Lists Register Login My Profile Inbox Address Book My Subscription My Forums

Photo Gallery Member List Search Calendars FAQ Ticket List Log Out

All Forums RSS Feed Subscription:

SMS packages AFTER deployment

View related threads: (in this forum | in all forums)

Logged in as: Guest

Printable Version

All Forums >> [Management Products] >> Operating System Deployment >> SMS packages AFTER deployment

Page: [1]

Message

<< Older Topic Newer Topic >>

SMS packages AFTER deployment - 9/3/2008 4:48:05 PM

EdwardKK

Posts: 138
Score: 0
Joined: 5/14/2007
Status: offline

Hi all,

OK, First, we're working with SMS2003 using ZTI (MDT2008) in an AD 2003 forest. I'm using OSD to deploy to new hardware that walks in the door. So, everything I image at the moment is a clean wipe and install. I allow the OSD process to generate the random workstation name, and then after OSD is complete, I manually rename the workstation to our standard. (I do this because I've got so many variables, it's just easier to manually rename the workstation and put it into the right groups/OUs when it's done.  We often image a machine in one office to be shipped to another office)   So, when OSD is completed SMS has registered the machine with a name like SMS-97097612347691 then I rename it to something like D630-001 and move it to the right OU's and Groups in AD.

I've got a large number of SMS packages which are assigned via AD groups or OUs. So, Office for example, would be assigned to a collection which has it's contents assigned by the contents of the "USA Computers Group" in AD. SMS checks AD groups regularly through the day and the collections are updated regularly as well. When things are 'normal' it all works peachy keen.

My challenge is after an OSD. When OSD finishes, it registers the new workstation into SMS with the random name (SMS-97097612347691 ) and assigns the GUID.   But when I rename the workstation, it's not updating the NAME of the system on the SMS server. the Workstation will be listed in SMS as SMS-97097612347691. The SMS server will see the AD account, and generate an SMS account (with no assigned GUID) for that workstation name and assumes it has no client. The SMS client on the workstation checks in regularly with the SMS server and sends inventory etc, but for some reason the GUID on the workstation in SMS is never reconciled with the new workstation name (D630-001). Instead I get 2 accounts. One called SMS-97097612347691   which is never assigned to any of my group/OU based collections because the name is incorrect, and another called D630-001, which is created during AD discovery, but never reconciles with the workstation's SMS client on that machine.

The end result is these machines never get the apps assigned to them via the group/OU memberships in AD.

If I go into SMS, and delete both the SMS-97097612347691   and the D630-001 records, and then let things sit for a couple hours, it synchs backup and all is happy. The SMS client re-registers with SMS and creates a new record and it reconciles with the AD discoveries. Then my adverts start to show up on the workstations.

Does anyone have any advice on how I can get these to reconcile without manual intervention?

Thanks!

Ed

Post #: 1

RE: SMS packages AFTER deployment - 9/4/2008 5:01:07 AM

marimar

Posts: 17
Score: 0
Joined: 1/23/2008
Status: offline

Hi Ed!

In what way would it be harder to use the MDT database to give each an every machine a name before beginning the deployment process, that is kept all the way through OSD and then later the SMS app deployment.

If you explain what your hardships are there, then perhaps we can suggest a workaround.
Problem with SMS are that even if you rename or reinstall the object, the old name is kept. Heck, even if you reinstall it, there will be multiple entries of the computer unless you delete them first.
Of course, you could make a script that updates the entry with the new name, but I still think my first suggestion would be easier to accomplish.

/Paul

(in reply to EdwardKK)

Post #: 2

RE: SMS packages AFTER deployment - 9/4/2008 8:51:38 AM

eschloss

Posts: 616
Score: 25
Joined: 9/7/2004
From: Cincinnati
Status: offline

I agree that auto-naming the system would be much easier.
Do you set the asset tag in the BIOS?
We name our systems off of the asset tag and we have our hardware vendor input the asset tag into the BIOS so we just put a line in CustomSettings.ini for ComputerName=%AssetTag% and it uses that value for the name.

(in reply to marimar)

Post #: 3

RE: SMS packages AFTER deployment - 9/4/2008 11:39:21 AM

EdwardKK

Posts: 138
Score: 0
Joined: 5/14/2007
Status: offline

Well, I'm thinking what I'm going to have to do is put a front end in place to assign a name prior to the OSD process and SMS assignments.

We have a large number of locations, but IT staff only sit in a few of those locations. We stage new machines in those locations and ship them to the other offices when new hardware arrives. Our challenge is that our naming conventions include locations. So, Denver machines are Den001, New York is NYC001, etc. So, if I use MDT to name it based on location, I still have the same problem as I will osd a machine in Denver, it will register as a DEN name, and then I have to rename it to NYC. In addition, to get the sequential numbering (den002, 003, 004, etc), I have to put together additional dbs, scripts etc which I don't have the resources or time to coordinate right now. But if you have any ideas, I'm happy to listen.

I've seen the pretty good front end scripts, and that might work for us. It looks like it would allow me to assign the name/Group/OU prior to installation and effectively solve my problems. I think for now, I'll just have to do some cleanup every few days.

I was just surpised that SMS didn't do it's own cleanup. Since machine information is really tied to the GUID, not the name, it seems to me that it would be logical that SMS would update a renamed machine in it's db. Let's face it, renaming a machine shouldn't be that big a deal. I had assumed (moron that I am) that SMS would update naming information just like it does Hardware and software and user account information. Does SCCM still work like this?

(in reply to eschloss)

Post #: 4

RE: SMS packages AFTER deployment - 9/5/2008 10:43:30 AM

marimar

Posts: 17
Score: 0
Joined: 1/23/2008
Status: offline

One would think that SMS should work better, but no... about SCCM, I have to get back to you on that one, but I think it handles this better.

Anyway, if you use the MDT database to name your machines it will solve your problem for you. Then you just use the parameter ComputerName=%OSDNEWCOMPUTERNAME%.
Of course, first you must manually enter the name in the MDT database for the corresponding computer, but once it entered, it will always get the same name no matter how often you redeploy it.

/Paul

(in reply to EdwardKK)

Post #: 5

RE: SMS packages AFTER deployment - 9/9/2008 12:53:25 PM

EdwardKK

Posts: 138
Score: 0
Joined: 5/14/2007
Status: offline

Thanks Paul, but that's exactly the point. I don't want to have to enter a computer into a db to name it, nor do I want it locked into a name. If I re-allocate that computer to another office, I will want to rename it. That renaming process should be a quick easy change, not something that requires me to modify a db in MDT. Adding the db to the equation means I have one more tool I need to update to move/rename a computer (AD, SMS, etc..... and now MDT).

What I liked about RIS was that I could configure RIS to name my systems based on the location of my RIS server and have it name systems based on my standards and sequences. OSD is clearly superior to RIS in many ways, but not in naming conventions. I really do miss that feature.

(in reply to marimar)

Post #: 6

RE: SMS packages AFTER deployment - 9/9/2008 6:14:21 PM

rbennett806

Posts: 840
Score: 15
Joined: 6/14/2006
Status: offline

I've run into the problem you're talking about on both SMS 2003 and SCCM 2007 and the solution is the same - use a custom front end. It would have been nice for Microsoft to actually think about things like this, but this is one more thing that's fallen through the cracks...

(in reply to EdwardKK)

Post #: 7