Software Installation. Remote application installation

Remote installation mode allows you to install programs from Kaspersky Lab and other manufacturers simultaneously on several devices on your network.

Kaspersky Security Center 10 Web Console performs remote installation of programs in the background. During a remote installation, you can use other program functions, as well as view information about the status of the remote installation for each of the devices on which the remote installation was launched.

To install the program on devices on your network using remote installation mode, follow these steps:

  1. Open the main program window.
  2. Select the Management tab.
  3. On the Management tab, select the section Managed devices.
  4. In chapter Managed devices select the Devices tab.
  5. On the left side of the window, click the Add button.

    The program installation wizard window will open with a welcome message.

  6. Click on the button Installation on one or more devices over a network using an installation package.

    A window will open Selecting an installation package.

  7. Select the installation package of the program you want to install from the list and click Next.

    A window will open with a list of devices on your network on which you can install the program.

  8. Check the boxes for the devices on which you want to install the program. If you want to install the program on all devices listed in the device list, select the Device name checkbox. Click on the Next button.

    A window will open Adding accounts(see picture below).

  9. Create a list of accounts that have administrator rights on the devices selected for installation (see the figure below):
    • To add accounts, do the following for each account:
      1. In the Account field, enter the account name.
      2. In the Password field, enter your account password.
      3. Click on the Add button.

        The added account will appear in the list of accounts at the bottom of the window.

    • To change account settings in the list of accounts, follow these steps:
      1. Select the account whose settings you want to change from the list of accounts and click the Change button.
      2. Change the account name in the Account field.
      3. Change the account password in the Password field.
      4. Click on the button Save changes(see picture below).

    The new username and password for the selected account will be saved.

    • To remove an account from the list of accounts, select the account you want to remove and click on the Remove button.
    • To change the order in which the program installation wizard will use accounts to access devices when you run remote installation on them, follow these steps:
      • To move an account up the list of accounts, select the account you want to move and click the Move button.
      • To move an account down the list of accounts, select the account you want to move and click the Move button.
  10. Start the process of remote installation of the program by clicking the Run button.

    The remote installation process will start on the selected devices. A window will open The program is being installed<Название программы> , which contains a list of application installation tasks on selected devices on your network.

    You can view the list of installation tasks using the following interface elements:

    The block of information about the device on which the remote installation of the program was launched contains the following information:

    • Device name. The name under which the device is registered on the network.
    • Status. Application installation status. After starting remote installation on the device, it takes the value Installation in progress.
    • IP address. Device network address.
    • Domain. The name of the network domain in which the device is registered.
  11. To complete the program installation wizard, click the Close button. Installation tasks will continue to complete.

    Devices on which remote installation completed successfully are automatically added to the administration group Managed devices.

Remote installation of a program may fail with an error (if, for example, such a program was previously installed on the device). Installation tasks that failed are displayed in the list of tasks with a status Installation error. If the remote installation of the application on one or more devices fails, you can install the application locally.

You can only run one remote installation task. If you run another remote installation task before the remote installation is complete, the current task will be interrupted.

Personal accounts for Viewers on NOIP (personal account). Audio-video chat in conference mode. Automatic import of computers from a domain, local network or with NOIP.

January 04, 2018

New version of LiteManager 4.8 with built-in network chat, NOIP jabber. New mode of operation Teacher, for conducting educational tests, collecting and distributing files in educational institutions.

LiteManager client for Android, OSX and iOS platforms.

July 06, 2015

LiteManager remote customer support

Program for remote client support Pro/Free version in one distribution. Remote access via the Internet via IP or ID connection. Remote desktop with support for the new Windows 10. Screen sharing mode allows you to organize the educational process in an educational institution, distance learning. Free for personal or commercial use.

June 06, 2015

New design of the LiteManager remote access program website, added a help system, overview of solutions, instructions for using the program, comparative reviews and articles. LiteManager with full support for running Linux under Wine, the program can now be run on Linux operating systems.

Remote installation and MSI Configurator

To install the program server module remotely, you must first create a connection to this computer.

We launch the remote installation mode through the main menu of the program or the context menu of the connection.

The remote installation window displays a list of computers on which installation will be performed and installation options.

Select the distribution package of the program's server module using the browse button.
If you perform a remote installation on a computer where there was no Litemanager server module before, the server will be installed without settings and you will not be able to connect to it, since the access password has not been set. Server settings can be set using the distribution configurator; if a server module is already installed on the remote computer, an update operation will occur, saving all program settings.

The distribution configurator can be opened by clicking the configure button.

Select Security and set a server access password.

After setting the required settings, for example, a security password, close the options window for the program’s server module.

You may receive an error message and you will need to run the program with administrator rights.

You must restart the Viewer client module with administrator rights and repeat the remote installation.

Now that the distribution is configured, we launch the remote installation using the Perform action button.

After installation, you can connect to a remote computer using the access password that was previously specified when configuring the server distribution.

Additional reference information

If WSUS is installed in a Windows domain, the administrator is happy and calm - they say, that's it, updates are installed automatically, traffic has decreased, there is no need to run around on computers, etc. In principle, everything else is the same, but not everyone uses Microsoft Outlook for work or Internet Explorer (although 8 is very good). There are many people who are accustomed to working with The Bat! mailer, Opera or Mozilla browser. If the question of updates arises, either this is a headache for the administrator in the form of running to each computer to update everyone, say, Opera, or users must sit under admins (albeit local, not domain).

Naturally, neither the first nor the second method is a solution. This means you need to be able to automatically install programs on workstations, and it is advisable to do this before the user has logged in - after all, once he has logged in, he will no longer want to reboot the machine, etc. The user must be confronted with a fact - the program, his favorite Opera, has already been updated and the admin does not care that for some reason he likes version 10.10 less than the previous one. An update just came out and needs to be applied. No options.

The most common answer to the question is HOW? - Of course, through Active Directory!- any specialist or just a system administrator will tell you. How about via AD?- you ask. And they will tell you - ?! You don't know how to use AD? Yes, it’s simple, through policy!- but most likely they won’t tell you anything more, because for most advisers this question is as unclear as it is for you. And you will have no choice but to google until you lose your pulse, because finding a huge volume on the topic “how to deploy Office 2007” on the corporate network is not a problem, but simply and in a nutshell - you will rarely find anything. Not without pride, I can say that this article is one of the few short and “no frills” articles that I have come across.

Installing programs from MSI

Let's say we want to automatically install (and install updates as updates come out) the Firefox browser. The msi file for Firefox can be downloaded (in a new window).

I will skip setting up the template.adm, because... This is not always necessary, and even more often you will find this template. As a result, the default settings (or, if we install on top of the old version, the settings will be saved). We don't need the.adm template.

Distributing access rights

I assume that all computer accounts (except domain controllers) are in the "OU Office Computers" OU.

Note 1:

Why is it better not to use the original computer location (Computers - Domain Computers in the Active Directory Users and Computers snap-in)? It is more convenient for me to manage policies for groups of computers in the future. In addition, when I attended Microsoft courses, I saw that on domain controllers in test systems and in “combat” systems configured by Microsoft specialists, almost only separately created OUs are used, and not basic ones. I decided for myself to repeat the experience of specialists. For now, this only makes me feel more comfortable. Naturally, IMHO.

Note 2:

Not all users need Firefox (just as not everyone needs The Bat, Opera, etc.). Therefore, we will create a separate group of computers in the “OU Office Computers” on which Firefox will be installed. For clarity, let's call the group GFirefoxComputers. I note that this will be a group, and not a nested OU!

We share some folder on the server (in the picture it is SoftwareDistibution, and not Mozilla Firefox, as it might seem) and give GFirefoxComputers group has read access, for the admin - full access (not to the admin's computer, but to the user - after all, you should be able to upload files to the share over the network;)).

In general, to check how everything works, you can do without the GFirefoxComputers group. Just so you don’t immediately complicate your life, and don’t blame group policies if something goes wrong;)

Politics rules the world!

On the domain controller, launch the group policy editor GPMC.MSC:

And we create a group policy associated only with our OU “OU Office Computers” called “Firefox 3.6.3 rus”:

Editing our policy "Firefox 3.6.3 rus":

Preparing a Firefox distribution for deployment on the network

In the "User Configuration" -> "Software settings" -> "Software Installation" section, right-click and create a new installation object - our future Firefox installer.

We select the MSI file, carefully placed by someone else in a shared folder. Important: you need to choose a network path to the file, not a local one, because users will have access to your installation not locally on the server, but over the network.

Select "Assigned":

This completes the work with the "Software Installation" branch.

Close all open windows on the server (if it does not interfere with other tasks, of course), Start -> Run -> gpupdate /force

Installation on workstations

Next, you just need to reboot your workstations so that Firefox is automatically installed BEFORE the window for entering your login/password appears. In other words, the user will be unable to not install something, forget it, etc. That’s why this method is so good. You remotely decide what will be installed/updated on workstations.

Windows XP sometimes does not “accept” new policies from the first reboot, so you can go to the user, run the command “gpupdate /force” (not necessarily as an administrator) and reboot his computer.

Be sure to check the installation on your / test computer BEFORE users come in the next morning and turn on their computers... what if it’s a mistake? Therefore, at least try it for yourself for the first time.

Additionally

Now, any new computer added to the OU Office Computers division will have the latest version of the Firefox browser installed. You don't even have to do anything. Simple and very useful. In the same way, you can install almost any software, including Adobe Reader, Adobe Flash Player (which normally require administrative rights to install), The Bat... but you never know how much software you have on your local network, which is one of the most important things to keep up to date. system administrator responsibilities.

A caveat: if you have already installed a package, in our case Firefox 3.6.3 rus, and after a while you will need to update it (because sooner or later a new version of the browser will be released), first remove the policy for installing Firefox 3.6. 3, then create a new one. Then "gpudate /force" and off you go!

). It solves the following problems:

  1. Remote administration
  2. Remote command execution
  3. Remote application installation
In fact, it is a convenient graphical shell for the utility psexec. The program window is divided into groups of fields and buttons corresponding to these three tasks:
  1. Host- IP address/name of the remote computer. The program constantly tries to connect to it and signals the result:
  • red- the computer was not found (it may have a firewall enabled).
  • yellow- the computer was found, but the credentials are incorrect / there are not enough rights / “simple file sharing” is enabled on the remote PC.
  • green- the computer has been found, the credentials are correct, the rights are available.
Here you can specify a list of computers. To do this, double-click in the empty field - the default list name will appear - @list. You can edit the list by double-clicking on it. There can be several lists, but they all must begin with the symbol " @ ".
  • User- account name for connecting to the remote computer.
  • Pass- account password for connecting to a remote computer.
    By double clicking here you can get the LAPS password - it will be copied to your clipboard.
  • During connection/installation, the credentials specified in the program settings, as well as those specified in the fields, are searchedUser And Pass.

    The program settings are read when it is launched from a filerinstall.ini, which can be located in directories"%PROGRAMFILES%\Rinstall\" And "%USERPROFILE%\Rinstall\"(the latter has priority).

    1. Remote administration

    1. - obtain information about the system.
    2. - get a list of installed software.
    3. - launch the computer management console.
    4. - launch a remote shell.
    5. - connect through the Configuration Manager client.
    6. - connect via remote desktop.
    7. - connect via remote assistant.
    8. - connect via TightVNC (Ctr+Alt+Shift+T - toolbar).
    9. - connect via Radmin.
    10. - open a remote resource.
    11. - see what space is occupied on the disks of the remote computer.

    2. Remote command execution

    1. - a command (launched file: *.exe, *.bat, *.cmd, *.vbs, *.hta, etc.) executed on a remote computer. The default command is to launch Device Manager.
    2. - Arguments (parameters/keys) of the command, if needed.
    3. [x]Copy- copy the command to a remote computer (you must specify its full path on the local computer).
    4. [x] Hide- execute the command secretly.
    5. [x]Wait- wait for the command to complete.
    6. - launch Far.
    7. - launch shell.
    8. - launch startup manager.
    9. - launch the uninstall manager.
    10. - update group policies (with the /FORCE key).
    11. - terminate all psexec processes.
    12. - update the IP address.
    13. - to restart a computer.
    14. - create a shortcut for an application that runs as a user with administrator rights (the free version of RunAsSpc is used).

    Commands are executed on a remote computer with rightsSYSTEM.

    It’s convenient to run as commands (don’t forget to check the box Copy). However, there are strange problems with launching SFX archives on remote computers with a 64-bit OS...

    3. Remote installation of applications

    Applications ( Rel Path) are located on any network resource ( Net Path). Access to it is carried out using credentials ( Net User, Net Pass). When installing an application on a remote computer, a network drive is connected ( Net Disk).

    Requirements for installed applications:

    1. The application must be located in a separate folder and installed automatically.
    2. The application folder must be written in the Latin alphabet.
    3. There should be a file inside the application folder install.bat, which installs the application. It is also desirable that this file supports the key -u(uninstall the application).

    Mine meet all these requirements.

    June 2

    A system administrator often has to install a lot of different programs and applications on the computers of company employees. Sometimes the number of these employees is too large, or the office is too large, for the administrator to run around all day and install these programs. This takes up a huge amount of time that could be spent on more useful things.

    How can I help the user without running across the entire office to him in order to install some Google Chrome?

    There are always several options. In this article I would like to consider one of them.

    Distributions in one folder and DameWare for installation.

    Setting up a shared folder on the server/personal computer. Create a folder (I called it Distr), go to its properties, tab: “Access” - “Sharing” button.

    Select “All” from the drop-down list and set its permissions to “Read”.

    To check the functionality of the folder, we can go to its address and see if everything is in order. Login to your computer via smb:

    1. you must know the name of your computer. (For me it will be Feanor184).

    2. Open any folder on your computer (for example, “My Computer”).

    3. In the top line of the address - where it says (My computer) select everything, erase and enter: //feanor184/ and press Enter.

    We open and see all our shared folders.

    The beauty and meaning of this red tape is that now we can get into this folder from any computer in our office network (provided that all computers in the office are on the same network).

    Install the DameWare client.

    Now we need to install the client. There is nothing complicated or unusual in its installation; it is installed like a regular program from the developer’s official website. We install the latest version - so that it is comfortable to work with Windows 8.1 - if such a need suddenly arises.

    I will probably describe the installation and detailed configuration process in future articles.

    Let's move directly to the purpose of our red tape. We also have a shared folder. Now we can connect to any computer on our network and install the software we need from the shared folder with our rights.

    We launch the client and see the following window:

    In the Host field, enter the name of the user’s computer (or its IP address) to which we want to connect and install the program.

    User Id is our login in the Domain.

    Password is our domain password.

    Domain - our domain (relevant if suddenly there is more than one).

    (IMPORTANT! In order for us to connect to a remote computer in this way, the user's Firewall must be disabled)

    After this, we get to the user’s computer, we can go to our folder (//feanor184/distr/) and install any programs.

    We will look at ways to install programs to users remotely using group domain policies.