Apply the software to a domain environment --

VeryMulti-software can be used normally in the administrator environment. However, after a domain user logs on to the workstation, the local user permission may be applied. This may cause many software to be started due to insufficient permissions, and thus cannot run. Here, we use Office2000 as an example to illustrate how to debug the software so that it can run in a domain environment. In fact, the reason for this operation is that every time the login user changes, after the office is started, the Office will check whether the directory of the relevant preparation file exists under % USERPROFILE %/Application Data/Microsoft, these directories will be used to store the startup preparation files for the relevant office suite. The first time you start the suite, you will call to check whether these directories exist in this path. If these directories do not exist, you will try to search for data1.msi to re-register user information based on the path registered in the Registry and create these directories. If the file cannot be found in the path or system path, a dialog box is displayed asking about the location of the file. If you can find this file, even if the current directory cannot be written, the system will not prompt an error and enter normally. This may be due to the design: So we generally have 3 methods to solve this problem. 1. Start the Office2000 suite in the administrator environment and copy the Administrator's profile. This action should be done by using an account other than the local administrator and domain user. Generally, it is better to use domain admin. The purpose of this operation is to avoid file occupation during the system's profile copying process, resulting in a copy failure. In "my computer" "user configuration file", select the Administrator profile, and then "copy" select the domain user directory under document and settings. OK. Select owner "change" and change to domain user. (Note: This step is very important. If you do not change it, after you copy it, you will use domain user to log on. The permission is completely administrator because it copies the Administrator's registry, all security policy settings are recorded in the registry. 2. Open a directory on fileserver and place data1.msi. Or place it locally (or simply put it in the netlogon directory :). Although feasible, it is not standard. I just want to make an example) and then change the location of data1.msi in the registry, point to them. The location of data1.msi in Office2000 is as follows: Windows Registry Editor Version 5.00 [hkey_classes_root/installer/products? E872dda-bf1096799c897e/sourcelist]
"Lastusedsource" = hex (2): 6e, 00, 3B, 00, 3B, 00, 5C, 00, 5C, 30, 00, 2e, 00,, 00, 35, 00, 30, 00, 2e, 00, 00, 2e, 33, 00, 5C, 00, 6f, 00, 5C, 00,00, 00 [hkey_classes_root/installer/products? E872dda-bf2136799c897e/sourcelist/NET]
"1" = hex (2): 5C, 00, 5C, 30, 00, 2e, 35, 00, 00, 2e, 00, 00, 2e, 00, 2e, 00, 33,00, 33,00, 5C, 00, 6f, 00, 5C, 00, 00 is followed by Hex data, it is visible in the registry. You can modify it before exporting and using it. As for how to distribute the registry, you can also write ADM, policy distribution, and script execution. 3. Run all the office suites in the administrator environment, and then add the related directories (word/Excel ......) under the Administrator's % USERPROFILE %/Application Data/Microsoft ......) directly copy to the corresponding directory under the domain user directory. Therefore, when domain users are started for the first time and subsequently, there will be no progress bar for re-registering user information. Note: Other software in the domain can run normally under the administrator, but the domain user cannot run normally after login. For example, Kingsoft is run after the domain user logs in and cannot display the dictionary. For example, the domain user logs in and cannot be translated. The former is because the domain user does not have the permission to read and write software/Kingsoft in the registry. You can grant this permission to the domain user. The latter is because the domain user does not have the permission to read and write the software installation directory, grant this permission to domian user. To implement a policy in a domain to grant domain users the read and write permissions on the registry key value and software installation path, follow these steps, you can combine the "login" and "File System" in the Security Attribute setting in the policy to distribute the policy (Sorry, the traditional name is used here, and the image below is used to describe its location)

By adding a machine code (primary key) in the login project, you can add a folder (folder) in the file system (NOTE: When specifying the folder path, in order to use Win2k and WINXP, use % SystemRoot %) to complete this. (Note: If no software to be debugged is running in the current system, the sub-key value of the software will not be generated. You can manually add this primary key. After the policy is distributed to the client, it is automatically applied to the corresponding key value in the client registry. When adding users, you can consider whether to use domain users or other permissions, click "reject" next to "modify". After the current primary key permission is inherited, if the following subkey already has the corresponding permission, the permission is denied first.) related information: for details about how to disable domain users from using USB, and how to disable domain users from running Windows built-in games, refer to [url] http://gnaw0725.blogdriver.com/gnaw0725/302835.html#/url].