How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.
Running Powershell Script To Join Domain after running Sysprep in Windows 7
I'm working on a Windows 7 image that will join the computer to the domain automatically. I'm trying to accomplish this through a Powershell script. While logged in as Administrator, I set the execution policy to remotesigned. Then I use Get-Credential to Store Passwords “securely” in a file (see http://bsonposh.com/archives/338). I create a script with the following commands:
$password = Get-Content c:\windows\system32\window
$credential = New-Object System.Management.Automati
add-computer -domainname Domain -credential $credential af.org -passthru
I save the script in c:\windows\system32\window
The problem:
1. It appears that Powershell reverts back to "Restricted" mode after running sysprep thereby not allowing scripts to run automatically.
2. It seems that the Administrator account seems to change because I get an error when trying to access the encrypted password file. I have to start running the Powershell cmdlets from scratch in order for it to work which defeats the automated process, but does join the domain.
I should note that my unattend.xml file changes the Administrator password. (Don't know if that has anything to do with it).
Please advise.
$password = Get-Content c:\windows\system32\window
$credential = New-Object System.Management.Automati
add-computer -domainname Domain -credential $credential af.org -passthru
I save the script in c:\windows\system32\window
The problem:
1. It appears that Powershell reverts back to "Restricted" mode after running sysprep thereby not allowing scripts to run automatically.
2. It seems that the Administrator account seems to change because I get an error when trying to access the encrypted password file. I have to start running the Powershell cmdlets from scratch in order for it to work which defeats the automated process, but does join the domain.
I should note that my unattend.xml file changes the Administrator password. (Don't know if that has anything to do with it).
Please advise.
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Create the folder C:\Windows\Steup\Scripts
Inside of scripts, create a file named SetupComplete.cmd. Commands that you place in this batch file will run just before you are presented with the Windows logon screen (after syspreping). Try calling your Powershell script by placing a command in the SetupComplete.cmd file. The Powershell script will have to be located somewhere on your computer.
One thing I'm unsure of and may work is placing the Powershell script directly in the scripts folder. It may run without the .cmd file.
Here is an article that may give you a few more sysprep tips.
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/Windows_7/A_3095-Windows-7-Sysprep.html
Let me know how it goes.
Inside of scripts, create a file named SetupComplete.cmd. Commands that you place in this batch file will run just before you are presented with the Windows logon screen (after syspreping). Try calling your Powershell script by placing a command in the SetupComplete.cmd file. The Powershell script will have to be located somewhere on your computer.
One thing I'm unsure of and may work is placing the Powershell script directly in the scripts folder. It may run without the .cmd file.
Here is an article that may give you a few more sysprep tips.
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/Windows_7/A_3095-Windows-7-Sysprep.html
Let me know how it goes.
Thanks Ivanoviola for your response and your article which I found most helpful throughout this process.
I'm still left with the problem of why I cannot access the encrypted password in Powershell when logged in as Administrator after the sysprep process. I can however run the script if I re-encrypt the file (see:http://bsonposh.com/archives/338).
Please advise
I'm still left with the problem of why I cannot access the encrypted password in Powershell when logged in as Administrator after the sysprep process. I can however run the script if I re-encrypt the file (see:http://bsonposh.com/archives/338).
Please advise
I read the posts and I understand what you're trying to achieve. It seems that when sysprep runs it resets the the key used to encrypt the file so it won't allow you to open it. I did come across a website that states:
• Do not encrypt any files or folders on your reference PC that you will be running Sysprep on. If you run Sysprep on an NTFS file system partition that contains encrypted files or folders, the data in those folders becomes completely unreadable and unrecoverable.
IV
• Do not encrypt any files or folders on your reference PC that you will be running Sysprep on. If you run Sysprep on an NTFS file system partition that contains encrypted files or folders, the data in those folders becomes completely unreadable and unrecoverable.
IV
Thanks Ivanoviola for your help. You are probably right.
I'm going to look into any possible work arounds to this question before closing it. I'll come back to this question. In the meantime, if you come across anything, let me know.
I'm going to look into any possible work arounds to this question before closing it. I'll come back to this question. In the meantime, if you come across anything, let me know.
Got it. It's a viable workaround to join the domain automatically and wirelessly.
1. First, we created a directory called c:\sysprep that would house the files and cmd files we create.
2. We then wrote a PowerShell script that will join the computer to the domain and saved it under C:\sysprep. That same script will delete all files in c:\sysprep
3. When creating the unattend.xml file, we ran two Synchronous commands under oobe system that would first set the execution policy in PowerShell to remotesigned. Then a second synchronous command that would call the PowerShell script to join the computer to the domain (which by the way, sets PowerShell back to restricted mode)
4. Since the wireless driver and software were already installed under the default profile, what happens after running sysprep and rebooting the machine, it will: one, ask for a computer name (this is because we left the computer name blank in the xml file. We did not specify that we wanted to join the domain in the unattend.xml file, we do that through PowerShell). Two, it will reboot and join the domain wirelessly. Voila!
After the second time it reboots, when you click on the "Switch User" button, you'll see a log in prompt to log in to the domain.
I've attached a sample of the files
autojoin.ps1.txt
sysprepgo.cmd.txt
Unattend.xml.txt
1. First, we created a directory called c:\sysprep that would house the files and cmd files we create.
2. We then wrote a PowerShell script that will join the computer to the domain and saved it under C:\sysprep. That same script will delete all files in c:\sysprep
3. When creating the unattend.xml file, we ran two Synchronous commands under oobe system that would first set the execution policy in PowerShell to remotesigned. Then a second synchronous command that would call the PowerShell script to join the computer to the domain (which by the way, sets PowerShell back to restricted mode)
4. Since the wireless driver and software were already installed under the default profile, what happens after running sysprep and rebooting the machine, it will: one, ask for a computer name (this is because we left the computer name blank in the xml file. We did not specify that we wanted to join the domain in the unattend.xml file, we do that through PowerShell). Two, it will reboot and join the domain wirelessly. Voila!
After the second time it reboots, when you click on the "Switch User" button, you'll see a log in prompt to log in to the domain.
I've attached a sample of the files
autojoin.ps1.txt
sysprepgo.cmd.txt
Unattend.xml.txt
Premium Content
You need an Expert Office subscription to comment.Start Free Trial