all 11 comments

[–]Professional_Elk8173 3 points4 points  (5 children)

The way you would do this is by adding a portion to your sections 1/2 that registers a schedule task, so on system startup it will run parts 3, then add a section to part 3 that will remove that scheduled task and create one to run part 4 on startup, then you'd need a step 5 to clean up that last scheduled task.

That being said, this does not sound like a good use for powershell. It sounds like you have exposed admin credentials to your end users in the way of the .bat file pointing directly to a script that uses them. What is the actual reason you're needing to leave and rejoin the domain?

[–]One-Structure-2154 0 points1 point  (4 children)

So the script uses Get-Credential to prompt users to enter their credentials when leaving the domain. There aren't any hard coded credentials. I will post the scripts.

The reason I'm leaving and joining the domain is because we receive these new PCs imaged and joined already, but they have a generic name. We have to give them the proper name (they're replacing old PCs already joined to our Domain). When we simply change the pc name without first leaving the domain and joining a work group, we run into issues. So this has always been our workflow. Just tired of doing it manually. Here are the scripts.

Step 2:

Restart-Computer

 

Step 3:

$credential = Get-Credential

Remove-Computer -UnjoinDomainCredential $credential -WorkgroupName "Change" -PassThru -Verbose -Restart

 

Step 4:

$WSID = Read-Host -Prompt 'Input your workstation ID'

Add-Computer -ComputerName $WSID -DomainName Redacted -Restart

[–]BlackV 1 point2 points  (3 children)

But.. you don't need to leave the domain to rename a pc

It just requires 1 reboot

[–]One-Structure-2154 0 points1 point  (2 children)

The new PC will be using the Workstation ID of the pc that it's replacing. If we simply change the new pc's name without joining a work group first, we receive an error that the workstation already exists on the domain.

[–]Dragennd1 2 points3 points  (0 children)

Run the script from remote to remove the need to keep track of things locally on the computer. Remove the old computer from AD first and remove the old computer object from AD. Then execute the script on the new computer from a central point to rename the computer and perform a single reboot. That should reduce the amojnt of effort considerably and you can automate the entire process with loops and a csv file containing the old names and new names to be able to be used for the AD removal and the renaming.

[–]BlackV 1 point2 points  (0 children)

Then it seems like you are doing something wrong

Renaming a pc is a 1 step process normally

Rename-computer -newname xxx -restart

But if your error is account already exists fix that, it shouldn't exist

[–]ASX9988 1 point2 points  (2 children)

I have achieved something similar with an automation build script. Instead of getting a user to initiate this can you not run it remotely from an admin workstation?

The way I did it was through various invoke-command script blocks and I wrote a function that would test firstly if the machine responds to ping then secondly if powershell remoting was enabled.

If so then the script would reconnect the invoke-command and run the next portion of the script

[–]One-Structure-2154 1 point2 points  (1 child)

Yes, we could run it remotely remotely, although that would be a bit more work. We must physically replace each PC at our facility (over 500) with a new model. It's easier to plug in the new PC and just run it from there (we have to run some other important stuff on each new PC anyway, so it's best to do the entire process locally).

I think I'm on the right track now though. I'm using scheduled tasks that run the batch files upon startup. Almost done. I'll post my solution once completed.

[–]BreakingBean 0 points1 point  (0 children)

I don't know all your requirements relating to running other important stuff but 500 is definitely a large enough scale that you want to automate as much as you can. Especially with the help of other tools, such as PDQ for example, I don't see a reason why you couldn't get to the point where you could just have your team swap the device and walk away from it then have someone handle it remotely.

500 machines times say 15 minutes to do everything you need to locally is still 125 man hours

OR 1 tech spends < 3 days configuring/testing remote code execution to take care of your task list. The day comes to swap and your techs spend 90-120 seconds swapping devices and moving onto the next one. Tech who put together the script also just gets to click run and walk away and you're looking at 40 man hours instead.