Gpo сценарий входа powershell

Опубликовано: 13.06.2017

Инструкция представляет шпаргалку по настройке автозапуска сценария при выполнении входа в систему Windows (login).

Настройка имеет некоторые нюансы, из-за которых, даже опытные системные администраторы не сразу могут понять причину неработоспособности сценария.

И так, запускаем консоль управления групповыми политиками и создаем новый объект GPO.

1. Разрешаем запуск скриптов.

Конфигурация компьютера Административные шаблоны Компоненты Windows Windows Powershell
(Computer Configuration  Administrative Templates  Windows Components  Windows PowerShell)

Находим параметр Включить выполнение сценариев (Turn On Script Execution) и выставляем значение Включить и в выпадающем списке Разрешить все сценарии.

2. Настраиваем время задержки для выполнения скриптов.

Конфигурация компьютера Административные шаблоны Система Групповая политика
(Computer Configuration  Administrative Templates System Group Policy)

Находим параметр Настроить задержку сценария входа в систему (Configure Logon Script Delay) и выставляем значение Включить и время задержки в минутах, например 1.

* как показала практика, лучше ставить хоть какую-то задержку.

3. Настраиваем автозапуск скрипта при входе.

Конфигурация компьютера (или Конфигурация пользователя) Политики Конфигурация Windows Сценарии
(Computer Configuration или User Configuration Policies Windows Settings Scripts)

В данной ветке мы увидим параметры для настройки сценария при входе или выходе из системы (включении или выключении компьютера). Дважды кликаем по нужному параметру и переходим на вкладку Сценарии Powershell (Powershell Scripts).

Нажимаем по Добавить и выбираем заранее написанный скрипт.

Если необходимо задать приоритет сценариям перед обычными сценариями, в выпадающем списке «Для этого объекта групповой политики выполните сценарии в следующем порядке» выбираем нужный пункт.

Обновлено 17.07.2019

Добрый день! Уважаемые читатели и гости одного из крупнейших IT порталов в России Pyatilistnik.org. В прошлый раз вы меня просили рассказать вам, о рабочих методах исправления черного экрана Windows 10 и я с вами ими поделился. Так как направленность моего ресурса больше рассчитана на системных администраторов и продвинутых пользователей, то я сегодня хочу вновь поговорить про групповые политики и автоматизацию получаемую благодаря им. В данной публикации речь пойдет, о запуске скрипта PowerShell средствами GPO (Групповой политики), мы рассмотрим все варианты доступные администраторам.

Постановка задачи

Когда начинающий системный администратор превращается в матерого админа, он хочет везде все автоматизировать и везде экономить свое время, и это логично люди существа любящие комфорт и лень. Рабочая среда Active Directory позволяет, как все знаете через групповые политики настройку почти всех компонентов в системе, а что не может замещается средствами PowerShell, вот такой симбиоз. В нашу задачу входит научиться запускать при загрузке компьютера или при входе пользователя на компьютер или сервер, наш скрипт PowerShell, который реализует ту или иную задачу, это не важно, пусть например монтирует базы 1С.

Методы запуска скрипта PowerShell через GPO

Существует несколько сценариев позволяющих вам применять к вашим объектам нужные скрипты:

1. Скрипт применяется в автозагрузке системы, в момент загрузки операционной системы
2. Скрипт отработает во время входа или выхода пользователя из системы
3. Ну и запуск скрипта по расписанию, такое то же имеет место быть

Запуск PowerShell скрипта в автозагрузке сервера

Открываем оснастку «Управление групповой политикой» и создаем на нужном уровне вашей иерархии организационных подразделений, новую политику, в моем примере, это будет «Добавление баз 1С». Переходим к ее редактированию.

Для того, чтобы при загрузке вашего сервера или компьютера, к нему применялся нужный вам сценарий PowerShell вам необходимо перейти в раздел:

Тут вы увидите два возможных варианта «Автозагрузка» и «Завершение работы»

Далее вы открываете пункт «Автозагрузка», переходите на вкладку «Сценарий PowerShell» и нажимаете кнопку «Добавить«. Через окно «добавление сценария» откройте папку «Startup» и скопируйте туда ваш скрипт. Теперь данный файл будет частью папки Sysvol и располагаться в конкретном GPO объекте.

Так же хочу отметить, что вы можете задать порядок выполнения PowerShell сценария в соответствующей области, выбрав будет ли он выполнятся после других сценариев или перед.

Еще есть ряд нюансов при использовании выполнения скриптов PowerShell средствами групповой политики:

1. Во первых по умолчанию в Windows есть 5-ти минутная задержка выполнения скриптом, как ее отключать я рассказывал можете почитать вот тут.
2. Если у вас в локальной сети присутствуют операционные системы по типу Windows Server 2008 или ниже, то там есть подводные камни в виде выполнения неподписанных скриптов и во вторых в старой версии PowerShell

Хочу отметить, что начиная с Windows Server 2012 R2, Windows 8.1 и выше, все запускаемые сценарии PowerShell через GPO работают в режиме Bypass, что подразумевает игнорирование политики Set-ExecutionPolicy. Но если у вас есть более старые клиенты, то вы можете пойти вот таким путем:

Вы можете явно указать исполняемый файл PowerShell, для этого в политике откройте вкладку «Сценарии», нажмите добавить. В имя сценария введите путь до файла powerShell, это:

В параметрах сценария введите вот такие ключи и сетевой путь до скрипта PowerShell.

Еще для подстраховки вы можете включить параметр GPO

Активируем настройку «Включить выполнение сценариев (Turn On Script Execution)», выставим значение «Разрешать все сценарии«.

Проверяем применение вашей GPO, если все настроили правильно она отработает если нет, то начинается траблшутинг, проверяете фильтры GPO и общий алгоритм поиска проблем.

Запуск PowerShell скрипта для пользователя

Чтобы применить к пользователю ваш скрипт, вам необходимо в объекте групповой политики открыть вот такую ветку:

Тут будет два варианта «Вход в систему» и «Выход из системы».

Настраиваем аналогично, как я показывал выше для компьютера, все одинаково.

Выполнение сценариев PowerShell по расписанию

Тут все просто, если вы хотите средствами групповой политики запускать скрипты PowerShell по расписанию, то вам нужно создать задание в шедуллере. Для этого есть ветки GPO:

Указываем в задании нужное время, имя и сетевой путь до скрипта.

Как видите все просто. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

August 14th, 2010

Summary: The easiest way to deploy a Windows PowerShell script to users is to create a Group Policy logon script.

Microsoft Scripting Guy Ed Wilson here. Oh…my eyes feel like they are glued to my eyelids. I am not a night owl, unlike the female who inhabits the house in Charlotte, who seems to enjoy howling at the moon on a regular basis. Anyway, I do like to read, and I found a fascinating book about Shakespeare for American readers at the library yesterday, and as soon as I began reading it, I felt compelled to finish it. Now it seems I must pay for my indulgence.

I received an email from one of my friends in Monterrey, Mexico, who was asking about running a script on his workstations to empty the recycle bin. I told him the best way to do this would be to configure either a logon or logoff script via Group Policy. I was in Monterrey several years ago and have taught VBScript, WMI, and Windows PowerShell workshops down there. It is a great town with excellent cuisine. Whenever I think of Monterrey, I am reminded of the Cerro de la Silla, which is shown in this photo I took during my last visit.

I woke up this morning with a plan. I wanted to configure the Get-ProcessStartUpTimes.ps1 script I wrote last week in a Weekend Scripter article to run on every computer on my network each time a user logs onto the network. In addition, because the Windows Search index service that exists in Windows 7 does not exist on servers, I need to ensure that the script does not run when someone logs onto a server.

To do this, I decided to create a new Group Policy object (GPO) and link it to my nwtraders.com domain in my forest. In the Group Policy Management Editor, I right-click the domain, and then click Create a GPO in this domain. This is shown in the following image.

Right-clicking the newly created GPO in the Group Policy Management Console and clicking Edit opens the Group Policy Management Editor, which is shown in the following image. Because I am interested in tracking not only processes that start after the user logs onto the computer but also processes that start before the logon screen, I configure a logon script for the user. There are startup and shutdown scripts that can be configured in Group Policy that are assigned at the computer configuration level, but they would not be the best place to obtain the information I’m looking for. To set a user logon script, open the User Configuration node of the Group Policy Editor, click Windows Settings and then click Scripts (Logon/Logoff).

I double-click Logon in the right side of the pane, and click the PowerShell Scripts tab as shown in the following image.

From here, I click Add, and click Browse. The Add a Script dialog appears. The Browse button opens a Windows Explorer window that is centered on the SysVol share for my domain. The cool thing is this is a great way to copy the script to the SysVol share, and I drag and drop my Get-ProcessStartUpTimes.ps1 script into the Logon script folder.

Because I do not want the script to run on my servers, I need to create a WMI filter. To do this, I right-click the WMI Filters node in the Group Policy Management Console and click New. The dialog appears that is shown in the following image. After adding my WMI query (tested using the Get-WMIObject cmdlet), I click Save.

The last thing I do is go to the AuditProcessStartUp GPO that I had created, and select the FilterWorkstation WMI filter I created.

Well, that is it. The GPO is now created, and I need to allow it to replicate among my various domain controllers. Tomorrow, I will create a Windows PowerShell script to connect to the network share and to parse the process objects.

We invite you to follow us on Twitter or Facebook. If you have any questions, send email to us at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson and Craig Liebendorfer, Scripting Guys

Windows Group Policy allows you to run various script files at a computer startup/shutdown or during user logon/logoff. You can use GPOs not only to run classic batch logon scripts on domain computers (.bat, .cmd, .vbs), but also to execute PowerShell scripts (.ps1) during Startup/Shutdown/Logon/Logoff.

In modern versions of Windows, you can directly run logon/logoff PowerShell scripts from a GPO editor (previously it was necessary to call the .ps1 file from the .bat batch file as a parameter of the powershell.exe executable).

Run the Domain Group Policy Management console (GPMC.msc), create a new policy (GPO), and assign it to the target Active Directory container (OU) with users or computers (you can use WMI GPO filters for fine policy targeting). Switch to policy Edit mode.

You must select a GPO section to run the PowerShell script, depending on when you want to execute your PS1 script:

• If you want to run a PS script when a user logon (logoff) to a computer (to configure the user’s environment settings, or programs: for example, you want to automatically generate an Outlook signature based on the AD user properties, customize screensaver or Start screen settings), you need to go to the GPO section: User Configuration -> Policies -> Windows Settings -> Scripts (Logon / Logoff);
• If you want to run the PowerShell script at a computer startup (to disable legacy protocols: NetBIOS and LLMNR, SMBv1, configure computer security settings, etc.) or prior to the computer shutdown, you need to go to the GPO section with the computer settings: Computer Configuration -> Policies -> Windows Settings -> Scripts (Startup / Shutdown).

How to Run PowerShell Scripts on Windows Startup with Group Policy?

Suppose, we have to run the PowerShell script at a computer startup. Select the Startup policy, and go to the PowerShell Scripts tab.

Now you need to copy the file with your PowerShell script to the domain controller. Copy your ps1 file to the Netlogon directory on the domain controller (for example, \woshub.comnetlogon).

Since we configure the Startup PowerShell script, you need to check the NTFS “Read&Execute” permissions for the Domain Computers and/or Authenticated Users groups in the ps1 file permissions.

Now click Add and specify the UNC path to your ps1 script file in Netlogon.

If you run multiple PowerShell scripts through a GPO, you can control the order in which the scripts are executed using the Up/Down buttons.

To correctly run PowerShell scripts during computer startup, you need to configure the delay time before scripts launch using the policy in the Computer Configuration -> Administrative Templates -> System -> Group Policy section. Enable the “Configure Logon Script Delay” policy and specify a delay in minutes before starting the logon scripts (sufficient to complete the initialization and load all necessary services). Usually, it is enough to put here 1 or 2 minutes.

On Windows Server 2012R2 and Windows 8.1 and newer, PowerShell scripts in GPO are run from the NetLogon directory in the Bypass mode. This means that PowerShell Script Execution Policy settings are ignored. If you want to run a script from a different shared folder, or if you still have Windows 7 or Windows Server 2008R2 clients on your network, you need to configure the PowerShell script execution policy.

By default, Windows security settings do not allow running PowerShell scripts. The current value of the PowerShell script execution policy setting can be obtained using the Get-ExecutionPolicy cmdlet. If the policy is not configured, the command will return Restricted (any scripts are blocked). The security settings for running the PowerShell script can be configured via the “Turn On Script Execution” policy (in the GPO Computer Configuration section -> Administrative Templates -> Windows Components -> Windows PowerShell). Possible policy values:

• Allow only signed scripts (AllSigned) – you can run only signed PowerShell scripts (“How to digitally sign a PowerShell script?”) — this is the best option from a security perspective;
• Allow local scripts and remote signed scripts (RemoteSigned) – you can run any local and signed remote scripts;
• Allow all scripts (unrestricted) – the most insecure option, because allows running any PowerShell scripts.

If not one of the settings of the PowerShell scripts execution policy is suitable for you, you can run PowerShell scripts in the Bypass mode (scripts are not blocked, and warnings do not appear).

To do this, run the PowerShell script from the Startup -> Scripts section. In this section, you can run your PS1 script by calling the powershell.exe executable (similar to the script described in the article). Set:

• Script Name: %windir%System32WindowsPowerShellv1.0powershell.exe
• Script Parameters: -Noninteractive -ExecutionPolicy Bypass -Noprofile -file %~dp0MyPSScript.ps1

The term %~dp0 is an environment variable that is automatically converted to a UNC path to the script directory (in this case, NETLOGON).

In this case, you are forced to allow any (even untrusted) PowerShell script to run using the Bypass parameter.

Reboot your computer to update the GPO settings and check that your PowerShell script runs after Windows boots.

Run Windows PowerShell Script at User Logon/Logoff

Let’s look at how to automatically run a PowerShell script when a user logs into (or logs out) Windows.

If you need to run the script not at computer startup, but after the user logs into Windows (for each user on the computer), you need to link the GPO to the Active Directory OU with users. In this case, the PowerShell script needs to be configured in the User Configuration section of your GPO.

If you want the policy to be applied to all users of a specific computer, you need to link the policy to the OU with computers and enable the Configure User Group Policy Loopback Processing mode parameter in Computer Configuration -> Administrative Templates -> System -> Group Policy). If you do not enable the loopback processing, then the parameters from the User Configuration section will not be applied to the user. For more information, check the post Group Policy Not Applying To User or Computer.

In this example, I will use a simple PowerShell script that writes the user’s login time to a text log file.

1. Copy your PowerShell script file to the\woshub.comNETLOGON folder on the Active Directory domain controller;
2. Go to User Configuration -> Policies -> Windows Settings -> Scripts -> Logon;
3. Go to the PowerShell Scripts tab and add your PS1 script file (use the UNC path, for example \woshub.comNETLOGONUserLog.ps1 );
4. Re-login the user on the target computer;
5. Your PowerShell script will be launched automatically via GPO when the user logs in;
6. You can verify that the user logon script was executed successfully by the Event ID 5018u nder Microsoft-Windows-GroupPolicy/Operational section of Event Viewer:

   Completed Logon script for woshubjsmith in 11 seconds.

   

If you want the user not to be able to access his desktop until the script is finished, you must enable the GPO parameter Run logon scripts synchronously (Computer Configuration –> Administrative Templates -> System -> Logon). In this case, the explorer.exe process will not start until all policies and logon scripts have been completed (this increases the user logon time!).

Note that the script runs with the current user permissions. If the user has administrative privileges on the computer and the User Account Control (UAC) settings are enabled, the PowerShell script cannot make changes that require elevated privileges.

In order to run PowerShell logon scripts with elevated user permissions, you can use the Scheduler Tasks.

1. Create a new Task Scheduler job under User Configuration -> Preferences -> Control Panel Settings -> Scheduled Task;
2. On the General tab, specify that the task will be started on behalf of the current user %LogonDomain%%LogonUser and enable the Run with highest privileges option;
3. On the Trigger tab, specify that the task should be started At log on;
4. Specify the path to your PowerShell script file on the Actions tab:

Action: Start a program
Program/Script: C:WINDOWSsystem32WindowsPowerShellv1.0powershell.exe
Add Arguments (optional): -ExecutionPolicy Bypass -command "& \woshub.comNetlogonYour_PS_Script.ps1"

Learn more about configuring Windows Scheduler tasks via GPO.

Such a PowerShell script will run as an administrator (if the domain user is added to the local Administrators group).

Some logon scripts need to be run for each user only once at the first login to the computer (initialization of the working environment, copying folders or configuration files, creating shortcuts, etc.). Here is a simple trick that allows you to run a script only once using GPO.

Logon scripts have been part of IT since the Stone Age it seems. Eventually we were also given logoff scripts for users as well as startup and shutdown scripts for computers. In the past these scripts were often written in VBScript. But now that we have PowerShell, we have another option.

Even though I am going to show you how to set up a Group Policy to run a PowerShell script, I encourage you to think about what you really need to accomplish. Many people still use logon scripts, for example, to do things that can now be done as a Group Policy preference such as mapped drives and printers. In fact Group Policy has come so far since the days of Windows 2000 that many organizations don’t really need a logon script. But if you think you do, the only things you should do in the script are those things for which there is no Group Policy setting. In other words, the exceptions.

Requirements

Now before you get to excited realize that your clients must be running at least Windows 7 or Windows Server 2008 R2. And while not a requirement, I’m going to encourage you to be running at least PowerShell 3.0. Remember that logon scripts run under the credential of the current user and it only makes sense that your logon script perform tasks specific to the user. Computer scripts should run under the system context which should give you more leeway. One area you might need to test is if your computer script, e.g. startup or shutdown, needs to access network resources. Credentials may be an issue.

I also encourage you to test your scripts interactively first to verify it works. Because the script runs in the background and invisible to the user, I also suggest testing your script as a background job. If it runs as a background job the odds are it will run as a Group Policy script.

Finally, I want to point out that Group Policy scripts will always run, regardless of your local script execution policy. Even if your execution policy is restricted Group Policy scripts will still run using a Bypass policy. The assumption is that if you have setup a Group Policy to run a script, you know what the script will do and are taking adequate steps to protect it.

Creating the policy

Let’s create a policy. In the screenshot below you can see I have the Group Policy Management console open. I’ve created an empty GPO called PowerShell Scripts and linked it to the MyTest organizational unit.

Group Policy Management Console

Edit the policy and navigate in the User node to the location shown below.

Logon / Logoff scripts

Double-Click on the type of script you want to create. I’m going to create a logon script which will give you in the next screenshot.

PowerShell scripts require at least Windows 7 or Windows Server 2008 R2

I’ve highlighted the fact that scripts need at least Windows 7 or Windows Server 2008 R2. Because it is possible you may have other types of scripts to run as well, you can control when PowerShell scripts are run in the drop down box as seen below.

Control when PowerShell scripts are run

For my test I’m going to run PowerShell scripts last. Now I need to add a script. The best approach is to click the Show Files button which will open an Explorer window for the GPO. Open another window with your script folder. Then simply drag and drop the file or files to the GPO as I do in the next screenshot.

Add PowerShell script to GPO

The files in the Logon folder will replicate and should be pretty secure. Once the file is copied I can go back to the Logon Properties dialog and click the Add button. I find it easiest to browse.

Browse logon scripts

This opens up the browse window again. Select the script and click open. If your script requires parameters, you can insert them as well. If all goes well you should end up with the following screenshot.

Logon properties

At this point the policy is complete. If you want to create a computer startup or shutdown script you would follow a similar process except under the Computer node.

Summary

Using PowerShell scripts through Group Policy opens up some tremendous possibilities primarily because you can do so much with a short script. Keep your scripts simple, test thoroughly and enjoy the benefits. In a future article I will share some sample PowerShell scripts that might make good candidates for Group Policy.