There are few ways to change OSDComputerName during the task sequence.
1. It can be set manually in CustomSettings.ini file before deployment begins
2. It can be set manually in first steps of deployment, in the preparation wizard.
3. It can be modified in a different ways using mostly VBS or PowerShell script in CustomSettings.ini or directly in Task Sequence environment parameters
4. The best way and way it should be is using MDT database (as I know).
Each approach has its own pros and cons, limitations and features.
Each approach is easier or harder to accomplish depends on experience.
My idea is a bit crazy but it works 😀
I wanted to obtain Zero Touch
I don’t know anything about MDT DB (I want to learn, the same as I want to learn new approach, PowerShell approach, to create deployment steps by Deployment Bunny
https://deploymentbunny.com/2016/05/18/osd-the-future-of-mdt-is-going-to-be-powershell ), but in it’s time.
I know PowerShell, so for now my way is this way:
I created a function which operates on two files. In one I keep information about computers which I want to deploy. Information like serial number of the computer which will be deployed, computer’s new name, user login who will be added to Administrators local group of this computer, Windows’ serial number to activate the OS, OU in AD to which computer will be added, and the key of a ticket from Jira in context of which this computer will be reinstalled (in one of the task sequence step I’m sending mail to Jira, to this ticket, that computer with specify SerialNumber was reinstalled). I’m also setting up TaskSequanceID so after I start the deployment using boot-able USB or PXE I have nothing else to do.
The CSV consist of headers:
The second file is the base configuration of which CustomSettings.ini is consist of the Default one.
The most important is, that in this basic file in the Priority section, on the first place is SerialNumber parameter and after it should be Default.
Why? Because what I do in the PowerShell script is taking this basic configuration and after it I’m adding (append) sections like this:
The steps which are performed by the script are:
1. Preparation (filling parameters, loading to memory the content of the “Computer Parameter database CSV file” and CustomSettings.ini file)
2. Blocking operation to others team members for the time of operation
3. Building new CSV file
4. Building new ini file
5. Exiting, letting other to perform the script
6. In case of error I’m cleaning up
The main imperfection in my concept is that the CustomSettings.ini file is unavailable for an average 0,03 seconds. In that moment if one of deployed computers would “ask” for the configuration ini file operation will failed and the Zero Touch would switch to Full Touch ;-). Deployment wizard started on the computer would have not data so the wizard would ask about every parameter to be filled in (computer name, administrator login and password, domain admin and password, bitlocker and other parameters).