A bad specialist is the one who has to run to all the workplaces and work with his feet. You need to work with your head :)

You can install the platform on each client computer manually.

But then the administrator will have to go through all the computers sequentially.
If there are 2-3 computers, then this is not a problem. But if there are a dozen or more computers, then this process may take a long time.

Updating the platform on client computers will also be a challenge.

To automate this process, you can use the ability to install the platform on a large number of computers through a shared network directory.

This method can be used when client computers have Windows installed.
The administrator places platform distribution kits and a set of configuration files in a common network directory.
To update the platform, you only need to place the new platform distribution in the common directory.

Mass installation and update of 1C: 9 videos and PDF

We invite you to look at more detailed materials:

Shared directory structure

This video describes how a network directory with platform distributions should be organized so that it can be used for installation on a large number of computers.
It is explained in what form the platform distributions should be uploaded and what configuration files are needed.

Preparing a shared directory on the server

This video discusses in practice how to fill out a network directory with platform distributions. The platform distribution is uploaded and the configuration launch is edited. Shows how to find the launcher for the desired release.

Actions on the client computer

This video discusses the features of installing the platform from a shared network directory on a client computer.

Platform update

This video explains how to correctly place the distribution kit of a new release platform in a common network directory. It describes what actions need to be performed on the client computer for the platform to be updated.

Configuration file defining the location of the shared network directory

This video explains where the network share settings are stored on the client computer, which should be accessed to check for a platform update.

Access rights when installing the platform through a shared network directory

This video explains the most common error that occurs when working with a network shared directory.

Working as a user without administrative rights

This video describes how you can install the platform on a client computer for a user without administrative rights. Attention is drawn to the disadvantages of this method.

Potential security issues when using the AlwaysInstallElevated policy

This video explains why the AlwaysInstallElevated policy is a serious problem for computer security and why you should avoid using it in practice if possible.

And the last day of starting discounts.

This course will allow you to solve ALL problems related to the deployment and support of information systems on 1C.

Here are some topics from the course:

• Installing and updating the 1C:Enterprise 8 platform – manual and automatic, for Windows and Linux
• Automatic start to perform routine operations
• Updating configurations from user mode
• Updating non-standard configurations. How to avoid problems when updating modified standard configurations
• Create your own delivery cfu files
• BSP tools: external forms, processing of filling out documents, etc.
• Usage free DBMS PostgreSQL
• Installation and launch server cluster 1C:Enterprise 8
• Administration Utility for setting up a cluster and worker servers
• Settings RLS using the example of UPP 1.3 and ERP 2
• What to do, if data in information security is corrupted
• Settings data exchanges between configurations
• Organization group development
• Setup and use hardware protection keys
• 1C software licenses: installation and binding to external equipment

In any case, at some point you will have to deploy 1C, configure reservations, access rights, various launch modes, test the integrity of the databases, ensure the operation of servers, etc.

And it’s better to do it right right away.

So that it doesn't happen later “...! Well what the...! Yours...!” – and other expressions of regret :)

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. The file names correspond to the Microsoft Windows decimal LCID representation (with the 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 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.

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 a web server.
CONFREPOSSERVER – 1C:Enterprise configuration storage server.
SERVERCLIENT – components for administering a cluster of 1C:Enterprise servers.
CONVERTER77 is a converter of 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 “/S” parameter and in the second command, the “/passive” parameter 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 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”.

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.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.

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?

1. 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 common with large software manufacturers, 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 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 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 on the local computer in the 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).

Near the rector July 26, 2014 at 01:09 pm

Connecting 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)

The automation tasks are similar: there are many 1C databases and an AD directory; a user who is in a certain AD group needs to be given the opportunity to launch a specific 1C database.

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 bitness of the platform. For version 1C 8.3 on the 32-bit version of Windows, the client is 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:

Adding a new database involves creating a new AD group, copying the shortcut to the 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