New deployment issue

[joeman1881]

Starting about a week ago I noticed an issue with PXE deployments. My task sequences are failing somewhere along the line, but I am not sure where. At first I thought it was related to my network card not installing correctly anymore so I rebuilt my driver package with the current release from MS (being that my primary test machine is a MS Surface). This didn't correct the issue. Then I noticed my command - net localgroup "Administrators" "DNAME\DOMAIN POWER USERS" /ADD - was failing. I then created a new task sequence but kept this step out because it was automatically failing the whole TS. The next issue I ran into was one of my packaged applications began to fail during deployment. After enabling "continue on failure" for my applications I was able to get my task sequence to deploy, but my driver package doesn't seem to have deployed correctly, my machine didn't add to the domain, and in turn, AV was not deployed. I have to be missing something super basic. I attached a copy of the smsts....Please help!

 

 

smsts.log

[joeman1881]

Update:

 

I ran this task sequence on a virtual per a co-workers recommendation. It worked without a hitch. I will add the net localgroup command back in, and the faulty application and see what happens.

[Peter33]

$objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-544")
$objLocalGroup = $objSID.Translate( [System.Security.Principal.NTAccount])
$strAdminGroup = ($objLocalGroup -split "\\").Get(1)
$group = [ADSI]("WinNT://"+$env:COMPUTERNAME+"/$strAdminGroup,group")
$group.Add("WinNT://DOMAIN/GROUPNAME,group")

Do not use this command to add Domain users/Groups to your local Groups. The command has a bug and will fail if the name length (including the Domain) exceeeds a specific number of chars (think it was 22?).

I am using a powershell script to add local group members (the above script: language neutral for the local admin group).

[joeman1881]

$objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-544")
$objLocalGroup = $objSID.Translate( [System.Security.Principal.NTAccount])
$strAdminGroup = ($objLocalGroup -split "\\").Get(1)
$group = [ADSI]("WinNT://"+$env:COMPUTERNAME+"/$strAdminGroup,group")
$group.Add("WinNT://DOMAIN/GROUPNAME,group")

Do not use this command to add Domain users/Groups to your local Groups. The command has a bug and will fail if the name length (including the Domain) exceeeds a specific number of chars (think it was 22?).

I am using a powershell script to add local group members (the above script: language neutral for the local admin group).

 

Thank you for this! I will add it to my deployment that I am about to test and report my findings!

[joeman1881]

So....I'm having an issue getting this to execute correctly. Forgive me for my lack of Powershell knowledge. I need to update the last line obviously, but the 4th line, am I modifying #strAdminGroup, group to match the machines local admins group? Or just modify the last line?

 

Thanks in advance!

[Peter33]

$group.Add("WinNT://MYDOMAIN/MYGROUP,group")

No problem. You just need to edit the last line, according to the name of your own AD group.

So if your group game is like MYDOMAIN\MYGROUP, the last line would look like this.

[joeman1881]

$group.Add("WinNT://MYDOMAIN/MYGROUP,group")

No problem. You just need to edit the last line, according to the name of your own AD group.

So if your group game is like MYDOMAIN\MYGROUP, the last line would look like this.

 

 

Great. I finally figured this out this morning using the Powershell ISE utility. What a great tool! When you deliver this in a task sequence, are you just creating a .ps1 file and then running a command prompt to launch the Powershell file, or is it better to package the Powershell file and deploy that way? CMD seems like it would be better, but I'm not sure how well it would work accessing from a network share.

 

Thanks again for the response.

[Peter33]

I am using a normal package, without a program, which holds several deployment scripts. In the task sequence i am using a command line step with this command:

powershell -executionpolicy bypass -file ".\scriptname.ps1"

This has the advantage that you can run the script with a different user account, for example to create AD objects or to modify AD group memberships.

[joeman1881]

I am using a normal package, without a program, which holds several deployment scripts. In the task sequence i am using a command line step with this command:

powershell -executionpolicy bypass -file ".\scriptname.ps1"

This has the advantage that you can run the script with a different user account, for example to create AD objects or to modify AD group memberships.

 

 

Ok, I will try putting it in a package and doing something similar then. I have other scripts we may be adding down the road so then I can just add them as you do in your environment.

 

Not sure if I should open another thread, but have you ever run into issues with 8.1 deployments where it stops after the initial windows boot to ask for your connection (wireless select or wired)? As soon as I choose it carries on with the task sequence and continues installing windows. So bizarre....

 

Its related to this thread issue which is why I ask...

[Peter33]

<OOBE>
     <HideEULAPage>true</HideEULAPage>
     <HideLocalAccountScreen>true</HideLocalAccountScreen>
     <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
     <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
     <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
     <NetworkLocation>Work</NetworkLocation>
</OOBE>

No, that's a completely different issue. You have to modify your unattended.XML file (oobe section) to disable this step.