Jeroen de Vroede was kind enough to provide his solution for store and retreive productkeys in the MDT database. Credits also goes to Rune Bakken and Ulrik Skadhauge Jensen for some of the stored procedure work.
In his own words: – I was trying to add functionality to the Stored Procedure that I could store and retreive productkeys. I work for a small company that uses OEM keys and it would be very nice to store the installation keys in the MDT database.
Solution overview:
The solution is based on a few components
CreateComputer – a stored procedure that generates a computer name based on prefix and a sequence number, and adds the computer to the database. The CreateComputer stored procedure will only add the computer to the database if it does not exist already in the database, and there is also logic in the CreateComputer stored procedure to assign different OU's depending on the machine being a laptop or desktop.
UpdateComputerInformation – a stored procedure that updates existing computers with serialnumber or macaddress and the product key.
MachineNameSequence – a table that keeps track of the generated computer names.
UpdateDB – a customsettings.ini file (named UpdateDB.ini) with instructions to call the UpdateComputerInformation stored procedure.
These steps assume that you already have a working MDT database and have assigned read and write permission for the account you are using in the deployment process.
Using Management Studio, execute the three SQL scripts, they will create the stored procedures and the table. If your MDT database is not named MDT, you need to change the SQL scripts to reflect that.
Grant execute permissions to the stored procedures for the account you are using in the deployment process. The account should already have read and write permissions to the MDT base.
Edit the MachineNameSequence table and type in a prefix and a starting number for the sequence.
Copy the Updatedb.ini file to your deployment share control folder
In the task sequence, create another Gather step under the Validate group, configure it to Gather local data and process rules, and to use the UpdateDB.ini file.
The Task Sequence with the extra Gather step added
Update your customsettings.ini with the below rules (or copy from the sample customsettings.ini in the download).
No, the account you use to drive the MDT deployment (do Not use Administrator). If you have followed my guides or books, the account would be named MDT_BA or BuildAccount, but it can really be any account.
/ Johan
lbrentj
9 years ago
I am having a problem getting the data stored in the DB. When you say 2.Grant execute permissions to the stored procedures for the account you are using in the deployment process are you talking about the local administrator account or some other? Brent
Admin
11 years ago
Yes, MDT 2010 Zero Touch has the same rules engine and database
/ Johan
Patrik
11 years ago
I guess this should work in an SCCM environment too? We use MDT integrated in SCCM and want to write ComputerName, SerialNumber and Adminpassword to the database. The reason why we want the AdminPassword written to the database is that it´s supposed to be unique on every computer.
Then we can read the AdminPassword from the database when it is needed.
Patrik
11 years ago
I guess this should work in an SCCM environment too? We use MDT integrated in SCCM and want to write ComputerName, SerialNumber and Adminpassword to the database. The reason why we want the AdminPassword written to the database is that it´s supposed to be unique on every computer.
Then we can read the AdminPassword from the database when it is needed.
Admin
11 years ago
AFAIK not all OEM licenses are bound to the BIOS (like Dell, HP, Lenovo etc are). It may also be useful for smaller organizations using retail media.
/ Johan
Martony
11 years ago
Why storing the OEM key in the MDT database? I also use OEM to deploy Windows 7 in my company and I don't need the installation key, Windows activates itself during deployment.
I don't know how it works exactly but all the DELL Computers in my company are deployed and activated without the key.
No, the account you use to drive the MDT deployment (do Not use Administrator). If you have followed my guides or books, the account would be named MDT_BA or BuildAccount, but it can really be any account.
/ Johan
I am having a problem getting the data stored in the DB. When you say 2.Grant execute permissions to the stored procedures for the account you are using in the deployment process are you talking about the local administrator account or some other?
Brent
Yes, MDT 2010 Zero Touch has the same rules engine and database
/ Johan
I guess this should work in an SCCM environment too?
We use MDT integrated in SCCM and want to write ComputerName, SerialNumber and Adminpassword to the database.
The reason why we want the AdminPassword written to the database is that it´s supposed to be unique on every computer.
Then we can read the AdminPassword from the database when it is needed.
I guess this should work in an SCCM environment too?
We use MDT integrated in SCCM and want to write ComputerName, SerialNumber and Adminpassword to the database.
The reason why we want the AdminPassword written to the database is that it´s supposed to be unique on every computer.
Then we can read the AdminPassword from the database when it is needed.
AFAIK not all OEM licenses are bound to the BIOS (like Dell, HP, Lenovo etc are). It may also be useful for smaller organizations using retail media.
/ Johan
Why storing the OEM key in the MDT database? I also use OEM to deploy Windows 7 in my company and I don't need the installation key, Windows activates itself during deployment.
I don't know how it works exactly but all the DELL Computers in my company are deployed and activated without the key.