/build/static/layout/Breadcrumb_cap_w.png

Post Installation Task to set registry values for all future profiles on machines not yet joined to a domain?

The K2000 comes with some baked in registry edit examples, but they are only good for the setup user and do not take effect on any subsequently created profiles.  I'm trying to enable Terminal Services so I can remote desktop into a Windows 7 Pro machine that has recently had a scripted install run (but not one of our scripts that joins a machine to our domain; where GP takes care of such settings).  Also, the final two post-install tasks on our scripted installs is to enable the local administrator account (set password and change  user name) and then finally to delete the setup user.  Is it possible to have a post-install task after we delete the setup user that logs the local admin into the machine, thereby creating the local admin profile and then I could run a registry tweak post-install that enables RDP?  Or is this a job for 'Active Setup' which I've just learned about but as of yet not found good documentation on?  

0 Comments   [ + ] Show comments

Answers (6)

Posted by: Nico_K 8 years ago
Red Belt
0
The post install tasks are running under the setup user environment, so you should delete it at last step (or disable it only)

As Post Install task I use this one for RDP enablement:

c:\windows\system32\reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

The best way (if you have one) is to use the K1000 for such tasks, because the K1000 can script and install more effectively.
Posted by: anonymous_9363 8 years ago
Red Belt
0
Don't forget to add users/groups to the local "Remote Desktop Users" group, too.

Thought, though...why not just add this stuff to your build?
Posted by: chucksteel 8 years ago
Red Belt
0
Nico_K's answer will enable remote desktop, which is a system wide registry key. It shouldn't matter what user you run that as, as long as they have admin rights on the machine. 

If you want to make changes to the default user profile you can use a script like this:
reg load HKU\Def c:\users\default\ntuser.dat
:CheckOS
IF "%PROCESSOR_ARCHITECTURE%"=="x86" (GOTO 32BIT) else (GOTO 64BIT)
:32BIT
reg import "excel-analysistoolpak-x86.reg"
GOTO END
:64BIT
reg import "excel-analysistoolpak-x64.reg"
GOTO END
:END
reg unload HKU\Def
This script loads the default user registry hive and then imports the appropriate registry keys depending on architecture. In this case the registry keys enable the Excel Analysis toolpak. The registry file has been modified to import into HKEY_USERS\Def and looks like this (32bit version):
Windows Registry Editor Version 5.00
[HKEY_USERS\Def\Software\Microsoft\Office\15.0\Excel\Options]
"OPEN"="/R \"C:\\Program Files\\Microsoft Office\\Office15\\Library\\Analysis\\ANALYS32.XLL\""
"OPEN1"="/R \"C:\\Program Files\\Microsoft Office\\Office15\\Library\\Analysis\\ATPVBAEN.XLAM\""

I'm curious why you create a setup user and then enable the local administrator account. Microsoft best practice is to leave the administrator account disabled and create a separate local administrator. This would simplify your workflow since you can just leave your setup user account in place as your local administrator account on the machine.



Posted by: SMal.tmcc 8 years ago
Red Belt
0
I do the admin login in 2 tasks.

Task1

net start w32time
%SystemRoot%\system32\w32tm /config /update /manualpeerlist:tmccacad.tmcc.edu /syncfromflags:manual

c:\windows\w2d\ksleep 10

net user administrator /active:yes
net user administrator PasswordHere

reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v AutoAdminLogon /d 1 /f
reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v AutoLogonCount /t REG_DWORD /d 10 /f
reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v DefaultUserName /d administrator /f
reg.exe add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v DefaultPassWord /d PasswordHere /f

reg.exe add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background" /v OEMBackground /t REG_DWORD /d 1 /f

del C:\Users\Default\AppData\Local\Microsoft\Windows\webcache\*.* /f /q
del C:\Users\Default\AppData\Local\Microsoft\Windows\*.log1 /f /q /a:hs
del C:\Users\Default\AppData\Local\Microsoft\Windows\*.log2 /f /q /a:hs
del C:\Users\Default\AppData\Local\Microsoft\Windows\*.blf /f /q /a:hs
del C:\Users\Default\AppData\Local\Microsoft\Windows\*.regtrans-ms /f /q /a:hs
del C:\Users\Default\AppData\Local\Microsoft\Windows\Explorer\*.* /f /q
del c:\users\default\downloads\*.* /f /q /s

"C:\Program Files (x86)\Microsoft Office\Office15\ospprearm.exe"
cscript "c:\program files (x86)\microsoft office\office15\ospp.vbs" /act
cscript %SystemRoot%\System32\slmgr.vbs -ATO

start /wait cscript.exe c:\windows\w2d\join_domain.vbs tmccacad.tmcc.edu installer PasswordHere

c:\windows\w2d\ksleep 10

(Check the box reboot required)

Task2

c:\windows\w2d\ksleep 10

start /wait msiexec /i "\\kbox.tmcc.edu\client\agent_provisioning\windows_platform\ampagent-6.4.180-x86.msi" HOST=kbox.tmcc.edu /qn

start /wait reg.exe add "HKLM\SYSTEM\CurrentControlSet\services\Tcpip6\Parameters\" /v DisabledComponents /t REG_DWORD /d 4294967295 /f

start /wait net user kprepper /delete

Posted by: SMal.tmcc 8 years ago
Red Belt
0
You can also modify the default profile when imaging this way

http://www.itninja.com/blog/view/how-to-make-changes-to-the-default-users-hive-as-a-post-taks
Posted by: anonymous_9363 8 years ago
Red Belt
0
Correct me if I'm wrong but I believe the default user is only used as a template for new *local* users, not domain users.

Comments:
  • You can configure machines to get a mandatory profile from the domain, but if not then they use the default profile on the machine. - chucksteel 8 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ