Jump to content

[sorta solved]Order of Specialize Pass; NetJoinDomain Fails; Set Compu


Recommended Posts

I need a method of renaming or otherwise setting/specifying the computer name *prior* to the machine joining the domain. Because the computer name must follow a specific pattern, and it must go to a specific OU, I can't just let good-ol windows name it to whatever, and I can't hardcode the OU in the XML.

  • I have a method of generating the computer name that works.
  • I have a method of assigning the correct OU that works.
  • I have placed unique markers in the sysprep XML so that I can perform a find/replace to assign the correct values.
  • The powershell script that does the find/replace works.

After being perplexed for hours, & testing within a PowerShell script during the specialize stage, I discovered that the machine joins the domain *prior* to processing the RunSynchronous commands. This is a problem. Whats the processing order? Can I move things around in the XML to 'force' X to run before B?

Since I had a prompt open during the specialize stage, I decided to try a different approach by renaming the computer via VBScript and PowerShell. However this failed because the Win32_ComputerSystem class isn't available.

I have not found a way of making my script run or otherwise setting the correct computer name before it joins the domain.

How can this be accomplished without requiring something to take place in the OOBE pass?

Edited by Phylum
Link to comment
Share on other sites


Computer_name is a string with a maximum length of 15 characters.

Important:

Computer names can be customized by OEMs and by corporate customers. They can append a string that is up to five bytes long to the customer-chosen computer name.

If they do not customize this string, "-PC" is appended to the customer-chosen computer name. In some languages, “-PC” is localized and the resulting string might be more than five bytes. When this occurs, the computer-name string is truncated and this truncation may result in a nonsense string appended to the computer name.

To avoid this situation, OEMs and corporate customers should provide an appending string in an Oobe.xml file.

They name ours out at work something like XXXX-1213 and thats also the asset tag then.

But you can't join the domain first so I'd think maybe set a random name and then after it joins you could read a file and rename the PC

Link to comment
Share on other sites

Thanks for the reply. Just so its known, I posted this on TechNet and this appears to be a 'known' flaw.

http://social.technet.microsoft.com/Forums/en-US/mdt/thread/771c18da-de2a-46b8-9a3a-1d0e07d127a9

The suggestion was to populate the XML file but that's just not feasible because there are properties (like the computer name and OU it needs to go into) that are unique to each machine. With multiple system types and departments, we've got quite a listing of OU's in AD. Desktops in the Desktop OU, Laptops in the Laptop OU, both of which reside under the appropriate department OU which resides under the Office (city) OU, which resides under the Region OU and so on. You eventally end up with something like

CN=WASH-D760-12345,OU=Desktop,OU=Engineering,OU=IT,OU=Puget,OU=Washington,OU=NA,DC=dom,DC=dom,DC=dom

At this point I only see two ways of accomplishing what I need/would like to have done.

1) During Specialize, run a script that will generate the correct computer name & rename the computer. It reboots & logs on for the first time and have it run another script (via FirstLogonCommands) to determine the correct OU and join the domain, into the correct ou, via Add-Computer.

Also, for me, Add-Computer isn't working the way I expected - perhaps I'm doing it wrong:

Add-Computer -DomainName "our.domain.com" -Credential $cred -OUPath "OU=Washington,OU=NA,DC=dom" -Server F.Q.D.N\DC1.F.Q.D.N

Add-Computer -DomainName "our.domain.com" -Credential $cred -OUPath "OU=Washington,OU=NA,DC=dom" -Server F.Q.D.N\DC1

Add-Computer -DomainName "our.domain.com" -Credential $cred -OUPath "OU=Washington,OU=NA,DC=dom" -Server DC1.F.Q.D.N

Add-Computer -DomainName "our.domain.com" -Credential $cred -OUPath "OU=Washington,OU=NA,DC=dom" -Server DC1

and some other variations with and without quotes for the domain name and OU. If I leave off the -Server parameter, it works, but frequently it joins a workgroup, not a domain. Odd. Ideas?

2) Populate bogus information in the XML file, like the computer name and OU, then, like above, have the machine run some scripts at some point to rename itself and move itself to the appropriate OU.

The last option was to create some custom properties in the customsettings.ini (CS) file to call an external script that would do what I need it to do. However, I've not found any samples/examples of this online, nor have I located any literature that covers this. I'm aware one can create multiple custom properties but I don't know what the proper syntax is, or how I can ensure it (my code/script) will run before a certain stage to make sure processes that need to happen actually run.

Link to comment
Share on other sites

What is stopping you from renaming the computer during specialize stage, then use SetupComplete.cmd to call a domain join script. I don't think the name change takes affect until after the reboot anyways. The machine reboots after specialize stage, so SetupComplete.cmd is likely the earliest you could run a custom domain script during the install.

Link to comment
Share on other sites

thats what I was thinking maybe with this

The Microsoft-Windows-UnattendedJoin component enables a computer to join a domain during the specialize Configuration Pass configuration pass.

By joining a computer to a domain, you can apply policies to the computer and access additional resources on the domain.

EX: download a file that has latest naming convention

Link to comment
Share on other sites

thats what I was thinking maybe with this

The Microsoft-Windows-UnattendedJoin component enables a computer to join a domain during the specialize Configuration Pass configuration pass.

By joining a computer to a domain, you can apply policies to the computer and access additional resources on the domain.

EX: download a file that has latest naming convention

That is exactly the problem the UnattendedJoin occurs before the Name change and he is getting random names in his OU. Plus he needs to be able to use the same install DVD and have the OU magically translated to the proper sub-OU in his domain.

What we do in the office (65,000+ desktops worldwide) is place all machines into the same provisional OU, and then use Altiris Agent (it's kinda like a rich man's PSEXEC) to run a few remote scripts after the build process is finished. It is much easier for us to handle this stuff outside of our image as we need to be able to update the scripts often. The Unattend.xml method seems like it was designed to benefit smaller companies who cannot afford to do a little manual scripting. (M$ has no remorse over making us do things the hard way. I view it as Job Security)

EDIT. We kinda do the same thing naming wise, ours is a two digit state code, followed by three digit city code, then the first 10 digits of Asset Tag or serial number. Makes it easy to guess which office the machine is from. For convenience we rename after the computer has joined the domain

i.e. TXHOU********** is a machine in Houston Texas, AZPHX*** is the Pheonix office, SPMAD might be in Spain. Scales really well.

Edited by MrJinje
Link to comment
Share on other sites

I was thinking -UnattendedJoin in specialize then get his file to do naming then perhaps a short and sweet Audit mode to update with scripts what he needs. Nothing set in stone you can't change before it hits the desktop. If thats not enough can then reboot from desktop for final changes, just a matter of figuring it out

I feel for you Phylum with all that mess

My XXXX-1213 is actually under one sub which is NAM meaning north America, looking under the list about 30 including China, but the 4 XXXX point exactly to where I am. They shortened this up immensely last change. No more OU

a Rant

Now they telling us all PC desktop's have to look the same in case someone comes to my plant and sits down at my PC they will have same thing, do they think all people are stupid? That's created in the profiles, we got some real winners in our IT. What a joke. where do these people get this stuff? Toyota. read the signs, they not so great as you idiots thought they were.

Edited by maxXPsoft
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...