So, what methods of deploying our software does 1C offer us?
1. Installation using logon script
2. Installation by placing it in a shared network directory
3. Installation using group policies
We reject the first two methods, because In this article we will look at installation using group policies (GPO).
The information on the 1C:ITS pages that the manufacturer offers us about deploying its product using group policies is very sparse:
When installing via group policies, to specify the installation language, you must specify the appropriate language transformation file. File names correspond to LCID decimal notation Microsoft Windows(with extension .mst). The transformation file for the Russian language is called 1049.mst.
In addition, you additionally need to specify the transformation file adminstallrestart.mst. In this case, the 1C:Enterprise system, if the versions of the client and server do not match, will prompt you to restart the computer for installation new version. The administrator must ensure that the new distribution has already been added in group policies.
Using group policies, you can install several versions of 1C:Enterprise.
To install a new version you need to create new installation in group policies.
1049.mst is obvious, but adminstallrestart.mst is not very useful. Therefore, we will create our own transformation file.
First of all, I would like to understand how we can indicate to the installer which components of the product we want to install and which we do not? Despite the fact that the documentation from 1c is generally quite extensive and detailed, for some reason not a word is said about this. But the logon script, which we rejected at the very beginning, will help us get out of this situation. In the script we can see the following lines:
CmdLine = cmdLine & " DESIGNERALLCLIENTS=1 THINCLIENT=1 WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=1 LANGUAGES=RU"
Where:
DESIGNERALLCLIENTS – all clients and configurator.
THINCLIENT is a thin client for client-server operation.
THINCLIENTFILE – thin client with the ability to work with file infobases.
SERVER – 1C:Enterprise server. If the installer is run from the launcher, the server will be installed as an application.
WEBSERVEREXT – extension components for the web server.
CONFREPOSSERVER – 1C:Enterprise configuration storage server.
SERVERCLIENT – components for administering a cluster of 1C:Enterprise servers.
CONVERTER77 – converter information bases from version "1C:Enterprise 7.7".
LANGUAGES – list of interface languages for installation. If several languages are specified, they are listed separated by “,”.
This line of the script generates a command line that will be sent to the msiexec installer for processing.
To create a transformation file we need the “Orca” editor. (http://www.technipages.com/download-orca-msi-editor)
And so, after installation, we launch the program. “File” – “Open”, and select “1CEnterprise 8.msi” from the 1C distribution kit. A list of tables appeared on the left side of the program, and table values appeared on the right. Because 1C itself does not recommend changing the msi package, so we go to the “Transform” – “New Transform” menu.
You need to go to the “Property” table. On the right side we look for the line “DEFLANGUAGE”, with the value “Auto”. The value must be changed to “RU” (Without quotes, of course).
For most users, you need to install a minimum of components, these are Thin Client, Thick Client, and language (for example Russian)
Therefore, let's create new fields (Ctrl+R), where you need to specify a name and value.
DESIGNERALLCLIENTS = 1
THINCLIENT = 1
THINCLIENTFILE = 1
SERVER = 0
WEBSERVEREXT = 0
CONFREPOSSERVER = 0
SERVERCLIENT = 0
CONVERTER77 = 0
LANGUAGES = RU
Those. It should look like in the pictures:
Next, go to the “Transform” menu – “Generate Transform...”. Save the file, maybe in the folder with the distribution, for example Client.mst
This completes the generation of the transformation file.
To check the installation, you need to open the “cmd” program. Go to the distribution folder. And run the command:
setup.exe /S TRANSFORMS=Client.mst TRANSFORMS =1049.mst
or
msiexec /i "<каталог с дистрибутивом >"TRANSFORMS="<каталог с дистрибутивом >"\Client.mst TRANSFORMS="<каталог с дистрибутивом >"\1049.mst/passive
In the first command the parameter “/S” and in the second command the parameter “/passive” means that the installation will take place in the background.
After some time you can check. Thick client, Thin client and Russian interface should be installed.
Next, you need to create a new installation in domain group policies.
You also need to create general directory on your network where they will be stored installation files. Check that domain users have read permissions from this directory.
Open the GP editor. We create a new policy. Open it for editing. Go to the section “Computer Configuration” - “Installing Programs”.
We create new package. We select the file 1CEnterprise 8.2.msi, the path to the file must be specified through the network environment \\SRV\…..\1CEnterprise 8.msi, we select the deployment method - a special one, so that modifications can be made.
After creating the package, the package properties window will open.
You need to go to the “Modifications” tab and add a transformation file for the Russian language called 1049.mst and a transformation file Client.mst.
After you click “OK”, it will not be possible to add modification files.
The package is ready. It is worth noting that the package must be applied to a group of computers; to do this, you need to create such a group in AD and place the computers for which installation is intended there.
When installing or updating a 1C Enterprise program, many administrators are faced with the impossibility of correctly performing these tasks using group policies. The most common error is 1720:
Product: 1C:Enterprise 8.1 - Error 1720.There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action customDetectPrevVersion script error -2147467259, Msi API Error: ProductInfo,Product,Attribute Line 7, Column 5
This error is caused by incorrect operation of the program update mechanism, that is, we cannot install a fresh build on top of the installed previous version.
To perform the update, you must manually edit the installation msi file before creating the group policy. To do this, we use Microsoft's free msi file editing tool called Orca. This utility is part of the Microsoft Windows Software Development Kit (SDK), and can also be downloaded separately.
- Download and install Orca;
- Open the file with the program 1CEnterprise 8.1.msi
- We find the section “ CustomAction" and in it the parameter " customDetectPrevVersion". Delete this parameter and save the changes;
- Copy to public network folder the distribution that is currently installed (if we update the build) and the new version 1C with the msi file we modified. We copy, naturally, to different folders
Now we need to create a group policy and create in the section " Installing programs» two installation packages - old (for example 8.1.11) and new (8.1.13) versions (Fig. 2).
Then, in the properties of the installation package of the new version of 1C, we need to indicate that this package performs an update old version 8.1.11 (Fig. 3). After assigning a policy, an additional restart of the computer may be required, since the removal of the old and installation of the new software versions are not synchronized.
Using group policies, you can install several versions of 1C:Enterprise.
To install a new version, you must create a new installation in Group Policy.
When installing via group policies, to specify the installation language, you must specify the appropriate language transformation file. The file names correspond to the Microsoft Windows decimal LCID representation (with the .mst extension). The transformation file for the Russian language is called 1049.mst.
In addition, you additionally need to specify the transformation file adminstallrestart.mst. In this case, the 1C:Enterprise system, if the client and server versions do not match, will prompt you to restart the computer to install the new version. The administrator must ensure that the new distribution has already been added in group policies.
You need to create a shared directory on your network where the installation files will be stored. Check that domain users have read permissions from this directory.
Open the GP editor. We create a new policy. Open it for editing. Go to the section “Computer Configuration” - “Installing Programs”. An example is shown in Windows Server 2008 R2.
Let's create a new package. We select the file 1CEnterprise 8.2.msi, the path to the file must be specified through the network environment \\SRV\…..\1CEnterprise 8.2.msi, we select the deployment method - special, so that modifications can be made.
After creating the package, I have about 30 seconds, the package properties window will open.
You need to go to the “Modifications” tab and add a transformation file for the Russian language called 1049.mst and a transformation file adminstallrestart.mst. It should look like this:
After you click “OK”, it will not be possible to add modification files.
The package is ready. It is worth noting that the package must be applied to a group of computers; to do this, you need to create such a group in AD and place the computers for which installation is intended there.
Near the rector July 26, 2014 at 01:09 pmConnecting 1C 8 databases using AD/GPO
- System administration
Good afternoon
Inspired by a recent post, I’ll share an alternative solution to this problem:
- without using scripts
- without editing 1C files (ibases.v8i, 1CEStart.cfg)
This method is convenient only if the user works with a small number of 1C databases (from one to ten), since it involves placing a separate shortcut on the desktop for each database.
Step 1.
Let's create a group in AD that includes a list of computers on which the 1C client is installed - it will include terminal farm servers, as well as computers on which the 1C client is installed. In fact, this may not be necessary, but we will use this group as an additional filter:
Step 2.
Let's create groups in AD for 1C database users: 
You may notice that a separate group is created to launch the database with other parameters (in this case in thick client mode).
Step 3.
Create a group policy that controls user shortcuts: 
Unfortunately, for 1C there is not yet a client version for the x64 platform, so the default location of the client depends on the bit capacity of the platform. For version 1C 8.3 on 32-bit version Windows client installed in %ProgramFiles%\1cv8\common\1cestart.exe, and on 64-bit Windows - %ProgramFiles(x86)%\1cv8\common\1cestart.exe
Now let's take a closer look at the creation of each element.
On the “General” tab, set the parameters for connecting to the database and the location of the shortcut (in this case, the desktop). An example of creating a shortcut for the Win x64 platform 
A small digression for those who are just planning to migrate from the 1C 8.2 platform to 8.3:
In the “General Settings” tab, let’s target our shortcut to the previously created AD groups: 
Setting for Win x86 platform: 
And for Win x64: 
Addition new base comes down to creating new group AD, copying the shortcut to GPO and editing the connection to the database.
P.S. If you have employees who independently place shortcuts on the desktop, then it is better not to use this method of accessing databases.
Thank you for your attention, I hope this post will be useful to you.
Tags: 1c, ad, gpo, links
Somehow I abandoned my cozy one. I'm correcting myself. Today we will talk about installing 1c v8.2 in a corporate environment using group policies. So, what methods of deploying our software does 1C offer us?
- Installation using group policies
We reject the first two methods, because in order to use them, the user must have local administrator rights (these are not our methods). It would be possible to use the script as a startup script, with a little addition to it. But, to be honest, I don’t understand: why use a script when you have the standard ability to deploy an application from an msi package using group policies. It would seem like another trivial case of software deployment in a domain. Now let’s go to the manufacturer’s website, read about how to set up an msi package, perhaps even download some tools for creating a transformation file (mst file), as is customary large manufacturers software, and the job will be done. However, this was not the case. The information that the manufacturer offers us about deploying its product using group policies is very meager:
When installing via group policies, to specify the installation language, you must specify the appropriate language transformation file. The file names correspond to the Microsoft Windows decimal LCID representation (with the .mst extension). The transformation file for the Russian language is called 1049.mst.
In addition, you additionally need to specify the transformation file adminstallrestart.mst. In this case, the 1C:Enterprise system, if the client and server versions do not match, will prompt you to restart the computer to install the new version. The administrator must ensure that the new distribution has already been added in group policies.
Using group policies, you can install several versions of 1C:Enterprise.
To install a new version, you must create a new installation in Group Policy.
The company 1c provided us with a very strange set of information: information about the transformation (modification) file 1049.mst is obvious, but information about adminstallrestart.mst is not very useful. First of all, I would like to understand how we can indicate to the installer which components of the product we want to install and which we do not? Despite the fact that the documentation from 1c is generally quite extensive and detailed, for some reason not a word is said about this. But the logon script, which we rejected at the very beginning, will help us get out of this situation. In the script we can see the following lines:
cmdLine = cmdLine & “THICKCLIENT=1 THINCLIENT=1 WEBSERVEREXT=0 SERVER=0 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=0 LANGUAGES=RU”
This line of the script generates a command line that will be sent to the msiexec installer for processing. As we can see, parameters of the form “Property=PropertyValue” are added to this line. It would be reasonable to assume that each of these properties should be reflected in the Properties table of the msi package. Having looked into the msi package using the Orca editor (which has already been written about on my blog), I did not see any of these properties in the 1c package. Therefore, just in case, .
So, we need to add several rows to the Properties table containing the corresponding properties and their values. Of course, we will not make changes directly to the installation package itself (msi file), but will prepare a transformer (mst file) using Orca. The screenshot shows the changes that need to be made to the installation package in order to indicate that we want to install only the thick and thin clients and at the same time select the Russian language for the interface (do not forget that we must not only select the Russian language for the interface, but also add it to the installation package using the appropriate transformer - file 1049.mst). I won’t talk about how to add an installation package and modification (transformation) files to group policy, I hope you know this, and if you don’t know, then you can.
It remains to consider the issue of adding information bases to the list that the user will see when starting the 1c program. Fortunately, since 1c v 7.7. a lot has changed and you don’t need to edit the registry for this. Information about databases is now stored in a file with the v8i extension. By default the file is located at local computer in a folder %APPDATA%\1C\1CEStart and has a name ibases.v8i. , but there are some limitations related to the fact that *.v8i files are files in the unicode format, and GPP cannot work with files in unicode encoding. Therefore, we have to make compromises, which you can read about in Sergei’s blog. But there is another way to create a list of infobases for the user, which does not have this drawback. Starting with v8.1, in 1c it became possible, having once registered an infobase in the list “by hand,” to upload a description of each infobase into a separate v8i file. Then, these v8i files can be placed on a shared network resource and added to users’ list of shared infobases. And, knowing that the general list of infobases is stored in a file 1CEStart.cfg, which is located in the folder %APPDATA%\1C\1CEStart, you can use GPP for these purposes without the problems that Sergey Betke encountered. I will give an example of the contents of a simple file 1CEStart.cfg(a description of the file format can be found on the website http://its.1c.ru, if you are the lucky owner of an ITS subscription).