Question: "Read so many masters of the post, but did not find a very simple answer to the question:
How do I set up a login script for a domain user?
-Can bat be used as a login script?
-How do I specify a login script name in the domain user properties? "D:\x.bat" or "\\srv\x.bat"? Or is it something else?
-Where should the script be placed?
-Are there any other issues you should be aware of? ”
(Attend the original post heated discussion http://www.winmag.com.cn/forum/itemdisplay.asp?boardid=24&id=393362)
1, bat can be executed as a login script, exactly what can be done on the Windows platform can be used as landing feet.
2, should be designated to \\server\ ... The path at the beginning of this format. Because the client executes the script at the time of landing, it is actually downloaded from the server to the local, and then executed. In this case, if you specify a path such as C:\, the client will only look in the local C disk instead of the path on the server.
3, the script can be placed in all the client can read the location. Usually this position is under the \\server\netlogon share (the location on the server is%systemroot%\sysvol\sysvol\domainname\scripts), but if you have a strategy, Then the default store path for the script should be under%systemroot%\sysvol\sysvol\domainname\policies\guid\user (machine) \scripts, if you put it in another location, You need to enter an absolute path in the position of the script execution bar, and the format needs to be \\server\ ... Beginning.
4, there are many other problems, in general, the script is applicable to the policy, the client may not be implemented.
There are a few reasons why you might be able to:
A, the script from the name to the content as far as possible do not use special characters, long file name (more than 8 characters), spaces, such as &. Such a script might be problematic on a different OS.
b, the location of the script and the path, please follow the above principles to do.
C, script writing aspect. In particular, apply net use to map a path on a fileserver. It is possible that before landing, the client already has the network disk mapping, if it happens to be the same as your map of the letter, will likely cause the script execution failure, you can in the front of the script add a net use */d/y to solve this problem.
However, this command should be used with caution, in the actual production environment, if your fileserver is Wintel platform storage, response time is long, then may cause the user to log in, can not connect fileserver Sharefolder, may use a sentence if exist to determine if the network disk exists.
On the other hand, if the remote device is a cross-platform storage device, such as some Nas, SAN, and so on, the map to the Windows platform may prompt "Network path cannot connect" and other issues, can be replaced map \\server_netbios_name or map \ \ Server_ipaddress two ways to try to connect.
If you encounter permissions issues, then the principle of minimum values when sharing permissions and security permissions conflict, you can generally set the share permissions to full control, and then security permissions to do a strictly defined way to solve.
D, "Profile path" and "Logon Script path", "Home folder"
When you first set up your domain account script, you might have some vague, difficult distinctions between these three concepts:
① uses Group Policy to edit a cmd at the place where the user logs in, and so on, using a method such as net use to map a network letter.
② "Compounding file path" refers to the position of the user profile, usually in the%userprofile%
"Logon script path" refers to the location of scripts executed when a user logs on to the server, usually the default path is located in the
Netlogon on the server, if scripting is used in a policy setting, the default path should be scripts under user or computer under the GUID of the GPO, and if placed elsewhere, the full path needs to be specified manually.
③ "Home folder" refers to the user's personal home directory on the Fileserver, which has no absolute location. You need to manually specify the path, but the difference between writing here and writing in the script is that the system automatically creates the folder based on the path you write, and assigns permissions to that user, which is the owner of the folder. Here you can use%username% variables to allow the system to complete itself. Of course, after you specify the home directory, you can still access other resources that have permission to use.
E, the order in which policies are executed is native, site, domain, OU, child OU. If there are duplicates on the settings, the following settings will overwrite the previous settings in the order in which they are executed.
If you set "Block Policy inheritance" on the OU, the top-level policies will not be executed at this level.
If you set "No override" on the OU, this layer will not be overwritten by the policy settings that follow, which means that even if the same settings are followed, the setting of this layer is still the same.
If you set "disabled" on the OU, this policy will be blocked from executing.
If you cancel the read and apply Group Policy for the corresponding group on the properties security of the policy, then the corresponding group will not be able to apply to the policy. Usually the default applied group has authenticated user.
If you cancel the group's two permissions and add other groups, and also give read and apply Group Policy, this policy will only be executed by that group, which is called filter.
If you have multiple DCs in your domain, you may need to synchronize them manually in Dssite.msc.
You can also use Secedit/refreshpolicy user_policy (machine_policy)/enforce on the server to force the refresh policy
This approach also applies to the client.
F, executed scripts that can be executed in Computer Configuration and User Configuration.
For user, you can usually place something that changes the user's properties.
For computer, you can usually place things that change the properties of your computer.
These two have no absolute boundaries, but are usually logged in as domain users, so that if you need to change the registry or system files and so on, you may encounter permissions issues, then we can also put such a script in the computer, which can be executed before user login.
(By the way: People rarely use computer accounts, then the role of computer accounts can be reflected here, because there is no user account verification, computer accounts and DC verification of the one hand from the local computer account and DC to maintain a password synchronization, To facilitate verification in this particular case, the password is changed by default 30 days.
You can even add computer account permissions on Sharefolder: If the password cannot be synchronized because of DNS correspondence or some other reason, the DC will not be able to authenticate the computer account, which may cause the computer logon script to fail. In the DC log, there is a general error indicating that computernetbiosname$ is not accessible. Workaround, you can reset the trust relationship by executing netdom on the client, which is another word. ）
For user settings, just log out and log in to get the application of the script.
For computer settings, you need to reboot the machine to get script execution.
Note: From the above points, you can see the computer in the landing time to use DNS to locate the DC, so as to locate
Location Gpo,sysvol (where policies, scripts, Administrative Templates are stored), DNS is critical for ad settings
, it is generally possible to set the DNS point of the client to the DC (if the DC is a dual NIC, then point to the internal
Network card DNS), and then set forwarding on the DC to forward to external (ISP) DNS.
The above is just a brief introduction to some common problems, if more complex problems, you need to consult other data to solve.
About the problems that people usually encounter, all sorted into the FAQ put in the following
★ See the configuration process you gave link: http://www.winmag.com.cn/forum/itemdisplay.asp?boardid=24&id=393362 but run or error?
My configuration process is as follows:
1, make the script file Config.bat and copy to the domain controller server under the Sysvol\sysvol\scripts directory
The script file uses the net use Z: \\linux_file\share command
2, configure the "configuration file path": Path point: \\nwf_sav (Domain control server name) \netlogon
To configure the logon script path: Config.bat
3. The following windows appear when the client logs off again: But the shared folder could not be mapped to a Z disk.
(Participate in the original post heated discussion http://www.winmag.com.cn/forum/itemdisplay.asp?boardid=24&id=509835)
Answer: There are two points of view for the location of the general script:
1, put the login script under the \\server\netlogon (the physical path on the DC is%systemroot%\sysvol\sysvol\domainname\scripts, not sysvol\sysvol\scripts)
When setting the login command file in the account attribute, this is the default location for landing scripts when landing the domain.
If you need to modify the script, you need to manually navigate to the path above,
The advantage is that the script is centrally placed
2. Place the login script under the path where the policy GPO is located (the physical path on the DC is similar to this
\\domainname\sysvol\domainname\policies\{142b4268-9574-471f-9f7f-9aa04836f57f}\user\scripts\logon, Here a long string of numbers is the GUID of the GPO, used to uniquely identify this object,
You can view the GUID by querying the properties of the policy.
When you log in to the command file in the settings policy, this is the default location for landing scripts when you log in to the domain
If you need to modify the script, click "Show file" below.
The advantage is strong and policy-related, edit find convenient
Either way, if the script is placed in the default query path, you do not have to write the path when you specify the log file
If not, you need to fill in the full path, which, of course, needs to be available to the client, which means
Cannot fill a path such as C:\winnt\sysvol\sysvol, otherwise the client will only
C:\winnt\sysvol\sysvol a lookup script on your own machine is obviously not found because the script
is downloaded to the local execution.
So let's see if the script can execute correctly on the client,
Winkey+r on the client, and then fill in the path of the script, such as \\servername\netlogon\config.bat
Will it be possible to wait until the correct result is performed?
Then see if the path specified in the position above is correct
If the login script is specified through the policy, we will use gpresult/v to see if the client has applied
The policy that you develop, if not, consider using Dssite.msc to manually synchronize all DCs in the domain, and then
Secedit/refreshpolicy user_policy (machine_policy)/enforce Force refresh policy,
Then the client logs back in or restarts (depending on whether you're making a user login script or a computer login script)
If it still doesn't work, then in the earlier article, it says,
It is possible that the Local has already map the same disk character disk, causing the conflict
It is possible that the shared path permission settings for the map are wrong, and common is the problem of setting the share permissions
It is possible that map sharing is a cross-platform storage device or format, and they may not be able to log on to a system-required
Time response, which causes the system to assume that the resource timed out the connection and is not available. You can try to replace the NetBIOS name or IP
See if any improvements have been seen.
If you have any further questions, you are welcome to continue the discussion!
This FAQ, I will sync updates in
http://www.winmag.com.cn/forum/itemdisplay.asp?boardid=24&id=393362
At the same time, you can also refer to "How to: Allocating Scripts in Windows 2000" HTTP://SUPPORT.MICROSOFT.COM/KB/322241/ZH-CN
