Maybe help a scenario in which profiles are created in advance.
Scenario 1:
Replacement of the shell explorer on the script with a call to mstsc.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Shell REG_SZ <script name>
Preparation:
- Make a profile on Terminal Server.
- Adjust the station on auto-login
Script body:
- Call mstsc.
- Logof part of the script. (This step takes a station in a cycle logoff-logon without giving the user perform malicious actions on the station outside the shell mstsc.)
You can really keep shift pressed, then there will autojoin
and you'll be presented with the login windows-domain password.
But if the station is not in the domain, this trick will do nothing.
Scenario Plus:
- no reboot required
- profile (with its settings and surrounded by its software)
- high security (the station may not necessarily be in the domain)
Cons:
- Writing a script for user logon
- RDP server infrastructure is needed
Scenario 2: Connect to the resource profile for the conference with the help of a script.
Preparation:
As further sub-options can be offered add and delete user props in the storage details, but it may be a resource conflict.
Scenario Plus:
- no reboot required
- connection resources of any user by login and password
Cons:
- Writing a script for user logon
- May require the creation or modification of architecture provide the user with resources.
Scenario 3: Creating a user profile in advance using a universal profile.
Preparation:
- Create a profile suited to all users.
- Add the appropriate permissions to
Domain Users
to the profile registry keys and profile folder.
- Restore a copy of the profile.
Need Rename key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID-Universal>]
=>
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID-Conference-user-logon>]
Rename record:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist]
\REGISTRY\USER\<SID-Universal> REG_SZ
\REGISTRY\USER\<SID-Conference-user-logon> REG_SZ
=>
\REGISTRY\USER\<SID-Universal>_Class REG_SZ
\REGISTRY\USER\<SID-Conference-user-logon>_Classes REG_SZ
Scenario Plus:
- Clean profile (if the user has a problem on your profile that here they will not)
- User security attributes.
Cons:
- Clean profile (will not be familiar user environment).
- Requires a reboot.
Scenario 4: Creating a user profile in advance on a copy of the user's profile in advance transferred to the machine.
Preparation:
- Login as a user to create profiles.
- Copy the user profile to the profile you just created.
- Change the permissions and correct entries in the registry
Scenario Plus:
- Profile user (with its settings, and part of his entourage without Software)
- User security attributes.
Cons:
- Profile user (profile problems may be such that no load)
- requires a reboot
Addition:
User name and the default domain
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
AltDefaultUserName REG_SZ <username>
DefaultUserName REG_SZ <username>
AltDefaultDomainName REG_SZ <domain>
DefaultDomainName REG_SZ <domain>
CachePrimaryDomain REG_SZ <domain>
Hide account who do not want to display, if necessary:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList]
<username1> DWORD 0
<username2> DWORD 0
...
<usernameN> DWORD 0
Do you have Roaming Profiles enabled on your domain? You may want to exclude this machine if you do... – Kruug – 2013-05-08T18:03:04.493
No we don't, the profiles are generated from scratch on each machine. – tvanover – 2013-05-08T18:10:16.433
trace the slow creating with xbootmgr/xperf: http://social.technet.microsoft.com/wiki/contents/articles/10128.tools-for-troubleshooting-slow-boots-and-slow-logons-sbsl.aspx
– magicandre1981 – 2013-05-08T18:27:19.503The machine is not booting slowly once the user account is created, it is only the login process when a domain user loggs in for the first time. – tvanover – 2013-05-09T19:17:40.993