Windows. Some basic methods for setting scripts

Q: "I have read so many excellent posts but have not found the answer to a very simple question:
That is, how to set a login script for a domain user?
-Can BAT be used as a login script?
-In the "attributes" of Domain Users, how should I specify the login script name? "D: \ x. bat" or "\ srv \ x. bat "? Or others?
-Where should the script be stored?
-Are there any other issues to be aware ?"

(Participate in the original post heated discussion of http://www.winmag.com.cn/forum/itemdisplay.asp? Boardid = 24 & id = 393362) Answer: 1. bat can be executed as a login script. To be exact, everything that can be executed on the windows platform can be used as a login script.
2. Specify \ server \...... The path starting with the format. Because the client executes the script during login, it downloads the script from the server to the local computer and then executes the script. In this case, if the path c: \ is specified, the client will only search for the local drive c instead of the path on the server.
3. scripts can be stored in the locations that can be read by all clients. This location is usually in the share of \ server \ netlogon (% systemroot % \ sysvol \ domainname \ scripts on the server), but if you have formulated a policy, the default path of the script should be % systemroot % \ sysvol \ domainname \ policies \ guid \ user (machine) \ scripts, enter an absolute path in the script execution column. The format must also be \ server \...... .
4. There are many other problems. Generally, when the script applies to the policy, the client may fail to execute the script.
Generally, there may be several reasons:
A. Do not use special characters, long file names (more than 8 characters), spaces, such as & in the script from name to content. Such Scripts may be executed on different operating systems. B. The script storage location and path should follow the above principles. C. writing scripts. In particular, net use is used to map the path on a fileserver. It is possible that there is a network disk ing on the client before login. If it happens to be the same as your map drive letter, it may cause the script to fail to be executed, you can add net use */d/y at the beginning of the script to solve this problem.
However, this command should be used with caution. In the actual production environment, if your fileserver is not a storage on the wintel platform and the response time is long, it may cause users to log on again, unable to connect to the snapshot folder on fileserver. You can use if exist to determine whether the network disk exists.
In addition, if the remote device is a cross-platform storage device, such as some nas and san devices, a message such as "network path cannot be connected" may be displayed when the remote device is mapped to the windows platform, you can try to connect map \ server_netbios_name or map \ server_ipaddress to each other.
If a permission problem occurs, set the shared permission to full control based on the minimum value when the shared permission conflicts with the security permission, then, strictly set the security permissions. D. When setting the domain account script for the first time, the "configuration file path", "login script path", and "Main folder" may be vague and difficult to distinguish, note: ① use the Group Policy to edit a cmd in the place where the user logs on to the script, and map a network drive letter using methods such as net use.
② "Configuration file path" refers to the location of the user profile, usually at % userprofile %
The "login script path" refers to the location where the script is executed when the user logs on to the server. The default path is
If a script is used in the policy formulation for netlogon on the server, the default path should be the user or computer scripts under the guid of gpo. If it is placed in another location, you must manually specify the full path.
③ "Main folder" refers to the user's personal home directory on fileserver. This concept 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 will automatically create a folder Based on the path you write and assign permissions to the user, the owner of this folder belongs to this user. The variable % username % can be used here for the system to complete. Of course, after specifying the Home Directory, you can still access other resources that have the permission to use. E. The policy execution sequence is local, site, domain, ou, and sub-ou. If there are repeated settings, the subsequent settings will overwrite the previous settings in the execution order.
If you set "block policy inheritance" On ou, the upper-layer policy will not be executed at this layer.
If "No override" is set on ou, this layer will not be overwritten by the subsequent policy settings. That is to say, even if the following settings are the same, the settings of this layer will still prevail.
If you set "disabled" On ou, this policy will be disabled.

If the read and apply group policies of the corresponding group are canceled on the properties security of the policy, the corresponding group cannot be applied to the policy. The group to be applied usually has the authenticated user by default.
If you cancel the two permissions of the group, add other groups, and grant the read and apply group policies to the group, the policy will only be executed by the group, this is the so-called filter.

If your domain has multiple DCS, you may need to manually synchronize them in dssite. msc.
You can also use secedit/refreshpolicy user_policy (machine_policy)/enforce on the server to forcibly refresh the policy.
This method also applies to the client.

F. The executed scripts can be executed in computer configuration and user configuration.
For users, you can usually place things that change user attributes.
For computers, you can usually place things that change computer properties.
There is no absolute limit between the two, but they usually belong to domain users members during login. In this way, if you need to change the registry or system files, you may encounter permission problems, in this case, we can also put the script in the computer so that it can be executed before the user logs in.
(The computer account is rarely used here, so the role of the computer account can be reflected here, because there is no User Account Verification yet, on the one hand, the verification of the computer account and dc comes from a password synchronization between the local computer account and the dc to facilitate verification in such special circumstances. The password is changed once every 30 days by default.
You can even add the computer account permission on mongofolder. :) if the password cannot be synchronized due to dns or other reasons, dc will not be able to verify the computer account, this may cause the computer login script to fail to be executed. Generally, an error message is displayed in the dc Log. ComputerNetbiosName $ cannot be accessed. The solution is to reset the trust relationship by executing netdom on the client .)
For user settings, you only need to log out and then log in to obtain the script application.
For computer settings, You need to restart the machine to obtain the script execution.

Note: from the above points, we can see that the computer needs to use dns to locate the dc when logging on to it.
Locate gpo and sysvol (policies, scripts, and management templates are stored here). dns is vital for setting ad.
In general, you can set this to direct the client's dns to dc (if the dc is a dual-nic, then point to the internal
Nic dns), and then set forwarding on the dc, forward to external (isp) dns.

The above is just a brief introduction to some common problems. If you encounter more complicated problems, you need to consult other materials to solve them.

For common problems, put them into the following faq:★Looked at the configuration process you give link: http://www.winmag.com.cn/forum/itemdisplay.asp? Boardid = 24 & id = 393362, but is it still an error?
My configuration process is as follows:
1. Create the script file config. bat and copy it to the sysvol \ scripts directory under the domain controller server.
The script file uses the net use z: \ linux_file \ share command.
2. Configure "configuration file path": Path to \ nwf_sav (domain control server name) \ netlogon
Configure "login script path": config. bat
3. The following window is displayed when the client logs out and re-logs in, but the shared folder cannot be mapped to the Z disk. (Participate in the original post heated discussion of http://www.winmag.com.cn/forum/itemdisplay.asp? Boardid = 24 & id = 509835) Answer: Generally, there are two ways to store scripts:
1. Place the login script under \ server \ netlogon (the physical path on the dc is % systemroot % \ SYSVOL \ sysvol \ domainname \ SCRIPTS, rather than sysvol \ scripts)
When you set the account attribute to log on to the command file, the default logon script location is found when you log on to the domain.
To modify the script, you must manually locate the above path,
Advantage: centralized script placement

2. Place the login script in the path of the gpo policy (the physical path on the dc is similar to this
\ Domainname \ SysVol \ domainname \ Policies \ {142b3168-9574-471f-9f7f-9aa04836f57f} \ User \ Scripts \ Logon. A long string of numbers is the guid of gpo, which uniquely identifies this object,
You can view the guid by querying the attributes of the policy)
When you set the policy to log on to the command file, the default logon script location is found when you log on to the domain.
To modify the script, click "show Files" below"
The advantage is that it is highly correlated with policies and convenient for editing and searching.

Either way, if the script is placed in the default query path, you do not need to write the path when specifying the login file.
If not, enter the complete path. Of course, this path must be available to the client, that is
You cannot enter a path such as c: \ winnt \ sysvol. Otherwise, when the client logs in
You cannot find the script in c: \ winnt \ sysvol on your machine, because the script
Is downloaded to the Local Machine for execution.

First, let's see if the script can be correctly executed on the client,
On the client, enter winkey + r and the script path, for example, \ servername \ netlogon \ config. bat.
Can I wait until the correct result is displayed?

Check whether the specified path in the above position is correct.

If you use the logon script specified by the policy, use gpresult/v to check whether the client has been applied.
If you do not have a policy, you need to use dssite. msc to manually synchronize all the dc in the domain, and then
Secedit/refreshpolicy user_policy (machine_policy)/enforce Force refresh policy,
Then, log on to the client again or restart the client (depending on whether you have prepared a user login script or a computer login script)

If the problem persists, as mentioned in the previous article,
It may be because the disk with the same drive letter has been mapped locally, resulting in a conflict.
It may be because map's shared path permission settings are incorrect, and common problems are the setting of shared permissions.
It may be because map sharing is a cross-platform storage device or format. They may not be required by the system during login.
The system considers the resource to have timed out and is unavailable. You can try to change the netbios name or ip address
See if there is any improvement.

If you have any questions, you are welcome to continue the discussion!
This faq will be updated on
Http://www.winmag.com.cn/forum/itemdisplay.asp? Boardid = 24 & id = 393362

You can also refer to how to: Assign scripts in Windows 2000 http://support.microsoft.com/kb/322241/zh-cn