Безопасность
Как уже отмечалось, использование сценариев VBScript/JScript представляет потенциальную опасность для системы — для их исполнения достаточно щелкнуть по значку мышью. Опасность еще более возрастает, если пользователь вошел под учетной записью, входящей в группу администраторов. В PowerShell скрипт с расширением невозможно запустить на исполнение с помощью мыши — в системе такой файл будет открыт не в командной оболочке, а в Блокноте. Для запуска сценария необходимо запустить саму оболочку PowerShell, ввести имя файла и нажать клавишу Enter.
В новой оболочке так же невозможна подмена команд. Суть этого приема, применяемого злоумышленниками, заключается в следующем. Обычно у пользователя, не имеющего прав администратора, есть некоторые папки с разрешениями на запись и выполнение файлов. Характерный пример — папка C:\Documents and Settings\имя_пользователя. Вредоносная программа создает в такой папке исполняемый файл с именем, совпадающим с именем команды оболочки или именем исполняемой системной программы. К примеру, я создал в «своей» папке документов ipconfig.vbs, выводящий простое сообщение. Теперь, если, запустив cmd.exe, и находясь в своей папке, я попытаюсь выполнить команду , то получу вот такой результат:
Для полноты иллюстрации можно поместить в папку с документами и исполняемый файл, переименованный в нашем случае в ipconfig.exe. Тогда даже при вызове с указанием расширения будет запускаться файл из текущей папки, а не из \system32. С PowerShell такой фокус не пройдет — для вызова скрипта, путь к которому не совпадает с путями, заданными в системной переменной %Path, необходимо явно указать его расположение. Даже в том случае, когда скрипт расположен в папке, являющейся для оболочки текущей, необходимо указать путь в таком виде: .\имя_файла. Точка с обратным слешем указывают интерпретатору на текущую папку.
Еще одним механизмом обеспечения безопасности является политика выполнения сценариев. Изначально оболочка настроена так, что даже при правильном вызове сценария его выполнение будет запрещено, а пользователь получит соответствующее сообщение. Политика выполнения может переключаться в один из четырех режимов:
- Restricted — настройка по умолчанию, запуск любых сценариев запрещен
- AllSigned — разрешен запуск сценариев, имеющих цифровую подпись надежного издателя; сценарии, созданные пользователем, также должны быть заверены центром сертификации
- RemoteSigned — разрешен запуск сценариев, если они не являются доверенными, но созданы локальным пользователем; сценарии, загруженные из Интернета, не имеющие подписи, не исполняются
- Unrestricted — разрешен запуск любых сценариев
Текущий режим политики можно узнать, выполнив команду в оболочке. Для изменения режима выполните команду с необходимым названием политики в качестве параметра.
Также к инструментам, помогающим повысить безопасность при работе с PowerShell, я бы отнес параметры команд из разряда «а что будет, если…». Их два — и . Первый позволяет определить, какое действие и с каким объектом будет произведено, однако само действие реализовано не будет. Что-то вроде моделирования. Второй перед выполнением действия будет запрашивать подтверждения пользователя, и в случае утвердительного ответа — запускать необходимую команду фактически. То есть, такой вид подстраховки.
Приведу, пожалуй, наиболее яркий и забавный пример использования этих параметров. Если пользователь попытается выполнить команду:
то через несколько секунд его будет ждать синий экран со STOP-ом. PowerShell, как и следует из текста команды, последовательно начнет «прибивать» все запущенные в системе процессы, что и приведет к ее критическому останову. Если же запустить:
ничего страшного не произойдет — просто PowerShell покажет, что бы он сделал, если бы команда выполнялась без ключа :
Что такое модуль PowerShell?
Модуль PowerShell — это совокупность функций PowerShell или сгруппированного кода, сосредоточенного вокруг общей основной темы. Все командлеты и поставщики PowerShell добавляются модулем или оснасткой.
Получатели этих модулей могут добавлять команды, содержащиеся в модуле, в свои сеансы PowerShell, чтобы использовать их как встроенные команды. Чтобы успешно сориентировать все функции в модуле вокруг одной и той же концепции, необходимо следовать некоторым рекомендациям, таким как отношения подсказок имен. напр. модуль Active Directory содержит функции, которые так или иначе взаимодействуют с Active Directory. Кроме того, все существительные в именах функций начинаются с AD, поэтому определенные функции легче обнаружить с организованной структурой имени.
Форматирование в Windows PowerShell
В Windows PowerShell существует набор командлетов, которые предназначены для форматирования вывода результата работы командлета. Они позволяют пользователю отобразить результат в том виде, в котором ему удобно просматривать данный результат.
- Format-List – вывод результата команды в формате списка свойств, где на каждой новой строке отдельное свойство;
- Format-Table — вывод результата команды в виде таблицы;
- Format-Wide — вывод результата команды в виде широкой таблицы, в которой отображается только одно свойство каждого объекта;
- Format-Custom – в данном случае форматирование вывода происходит с использованием пользовательского представления.
Еще немного полезных ссылок
Вот этот гайд описывает как запускать процесс от имени имперсонированного пользователя. Вторая ссылка — как получить то что выводится в стандартный вывод.
ASP.NET Run Process As Impersonated User: https://support.microsoft.com/en-us/help/889251/how-to-spawn-a-process-that-runs-under-the-context-of-the-impersonated
Вот тут написано как человек пытается получить вывод от процесса запущенного с помощью CreateProcessAsUser:
А вот тут представлен класс, который по идее это все делает. но у меня не получилось 
https://stackoverflow.com/questions/27986399/capture-standard-output-from-createprocessasuser-in-c-sharp
Вот тут написано как из приложения ASP.NET запустить процесс от имени импесонированного пользователя, указав имя и пароль (Impersonate a Specific User in Code): https://support.microsoft.com/en-us/help/306158/how-to-implement-impersonation-in-an-asp-net-application
Вот тут понятные классы, которые помогают запустить процесс от имени конкретного пользователя: https://habr.com/ru/post/135299/
Вот ссылки описывают как создать проект, однако в них не работает имперсонализация пользователя.
http://jeffmurr.com/blog/?p=142 https://incoherenttruth.wordpress.com/2011/01/05/execute-powershell-cmdlets-from-asp-net-with-user-impersonation/
Change ASP.NET Settings per pool. https://weblogs.asp.net/owscott/setting-an-aspnet-config-file-per-application-pool https://discussions.citrix.com/topic/277547-impersonation-seems-not-to-flow-to-powershell-runspace/
PowerShell UI Using Jenkins
https://hodgkins.io/automating-with-jenkins-and-powershell-on-windows-part-1 https://hodgkins.io/automating-with-jenkins-and-powershell-on-windows-part-2
Powershell UI Using ASP
http://waynes-world-it.blogspot.ru/2008/05/running-powersell-scripts-from-aspnet.html
Making a powershell script run from aspx – it worked in 1/2 hour!
Для создания web-страницы, которая сможет запускать PowerShell-скрипт потребуется:
- Разместить aspx-файл в корневой папке web-проекта.
- Разместить web.config в корневой папке web-проекта.
- Если web-приложения работает от имени Network Service, то дать этой службе права на чтение.
- Собственно сам скрипт PowerShell
- Библиотека (dll) System.Management.Automation в папке .\bin
Для вывода строк следует использовать Out-String. Для передачи параметров следует использовать $args.
Вступление
Немалая часть задач, связанных с обслуживанием локальных вычислительных сетей, представляет собой выполнение рутинных операций, ручная реализация которых может потребовать значительного времени. Вероятно, решения, позволяющие автоматизировать выполнение административных задач, которые могли бы повысить производительность, возникли почти сразу же с появлением профессии системного администратора.
Наиболее распространенным средством «экономии времени и избавления от головной боли» стала запись и последовательное пакетное исполнение необходимых операций — исполнение сценариев или скриптов в интерпретаторе команд операционной системы.
Попытки улучшить состояние дел в области управления и администрирования Windows с помощью командного интерфейса привели не к адаптации чужеродного для системы языка сценариев или созданию супер-утилиты, работающей в DOS, а к появлению PowerShell – новой командной оболочки.
В составе MS-DOS и Windows 9x таким интерпретатором, позволяющим выполнять обработку пакетных файлов (bat-файлов), являлся command.com, впоследствии (начиная с выхода Windows NT) замененный cmd.exe. Позднее появился Windows Script Host.
Тем не менее, процесс написания и выполнения сценариев в ОС Windows не развит так хорошо, как, например, в UNIX-системах. Одна из причин этого – сам графический интерфейс ОС Windows, видимо и сделавший ее столь популярной среди обычных, не корпоративных пользователей. Возможность управления некоторыми элементами среды Windows с помощью графического интерфейса не всегда можно реализовать с помощью системных утилит, выполняемых в командной строке. С другой стороны, возможности каких-то системных программ, поставляемых в составе Windows, не всегда представлены в GUI. К тому же интерпретаторы в Windows имеют довольно ограниченный набор команд, «зашитых» в саму оболочку. Windows Script Host не интегрирован с командной строкой и сам по себе представляет потенциальную опасность – его использует достаточно большое количество вредоносных программ.
Попытки улучшить состояние дел в области управления и администрирования Windows с помощью командного интерфейса привели не к адаптации чужеродного для системы языка сценариев или созданию супер-утилиты, работающей в DOS, а к появлению Windows PowerShell – новой командной оболочки. По некоторым данным, ее появление связано с использованием платформы .NET при создании командного интерфейса для WMI. В данный момент PowerShell является отдельным приложением, который можно установить на любую систему, использующую платформу .Net 2.0 (Windows XP, Vista, Server 2003). Начиная с Server 2008, PowerShell будет являться встроенным компонентом Windows-систем. Если же у вас не Server 2008, для знакомства с PowerShell предварительно необходимо будет его загрузить (возможно, вам понадобится и установка .NET).
How Many Profiles Do You Need?
Any standard Windows system has two profiles for the standard PowerShell host, two for the PowerShell ISE host, and two for all hosts-six in all as a minimum. Add in the VS package manager that I have shown, that’s two more. Add other PowerShell IDEs-two more for each. How do you manage so many profiles?
Interpreting official MSDN doctrine ( about_profiles) consider a tripartite solution.
- First, put truly common things in .
- Second, if there are some peculiarities in particular hosts, use for those miscreant hosts.
- Finally, let each user manage his/her own preferences and settings in user-specific profiles.
But again, there could be many different profiles for “current host”, both at the system level and at the user level. One good reference, as you are mulling over your choices here, is Ed Wilson’s (The Scripting Guy) post Deciding Between One or Multiple PowerShell Profiles. He includes in there a list of advantages and disadvantages for choosing between one profile and multiple profiles. But to me, the advantages of a single profile far outweigh the advantages of multiple profiles. It takes a little more work to set up, but you can still account for host-specific differences while having everything in one place, making it much simpler to maintain over time.
Most of your profile stuff will probably be common to any host, so using a single profile means that any changes down the road will be done in exactly one file. For the stuff that differs amongst hosts, just include a section specific to each host you care about. Mine includes something like this:
|
1 |
if($Host.Name-eq’ConsoleHost’) { Import-ModulePSReadline # differentiate verbose from warnings! $privData=(Get-Host).PrivateData $privData.VerboseForegroundColor=»cyan» } elseif($Host.Name-like’*ISE Host’) { Start-Steroids Import-ModulePsIseProjectExplorer } if(!$envgithub_shell) { # not sure why, but this fails in a git-flavored host Add-PSSnapinMicrosoft.TeamFoundation.PowerShell } |
Notice how I identify the current host with then selectively execute code. You see examples above for the standard PowerShell host as well as the PowerShell ISE host. For the former, it loads the PSReadline extension which only works in the PowerShell host. For the latter, it loads the PsISEProjectExplorer and the ISE Steroids module, both of which can only function in the ISE environment.
Finally, if you use Git and the particular installer you used created a Git PowerShell host for you, note that it cannot be distinguished from the standard PowerShell host by the . Instead, I identified a uniquely defined variable, , which is only present in the Git-flavored host.
Профиль
Профиль это файл, который запускается при запуске PowerShell, если это разрешено политикой выполнения (гугли Get-ExecutionPolicy, Set-ExecutionPolicy)
Профиль может быть системным или пользовательским. Первый расположен здесь $PROFILE.AllUsersAllHosts, второй здесь $PROFILE (он же $PROFILE.CurrentUserCurrentHost). В момент запуска PowerShell считываются оба профиля, сначала системный, затем пользовательский. Если разливать профили доменным пользователям, я рекомендую разливать только системный профиль, т.к. он хранится в system32, а пользовательские профили оставлять пользователям на усмотрение.
Туда можно записать любые значения, хранить там переменные, функции, текст, да хоть учетные данные.
Зачем тогда весь этот вышеизложенный текст, я ведь могу запихнуть функции в профиль?
Да, у меня в профиле около сотни строк, а функций всего две-три, и это самые основные функции, которыми настраивается оформление и пути к скриптам.
А если вам срочно нужно поправить баг в каком-то скрипте и запустить его в окне консоли, в которой уже есть очень важная инфа и ее нельзя перезапустить?
Тогда становится ясно, что хранить свои скрипты в профиле нельзя.
Кстати мой профиль:PowerShell $Profile.AllUsersAllHosts
Продолжение PowerShell Scripts (part 1)
Установка модулей PowerShell
Установка модулей очень простой процесс. Чтобы найти установленные, но еще не запущенные модули, запустите теперь известную команду Get-Module -ListAvailable.
Чтобы получить список только импортированных модулей в текущем сеансе, просто запустите Get-Module.
Далее при наличии на компьютере интернета произведем поиск нужного модуля, например VMware.PowerCLI. Для этого есть командлет Find-Module. Выполним команду:
Find-Module -Name VMware.PowerCLI
Можно найти модули с похожими именами. например все, что связано с Vmware.
Find-Module -Name VMware*
Можно найти модуль по минимальной версии или по конкретной версии.
Find-Module -Name VMware.PowerCLI -MinimumVersion 12.5.0.19195797
Find-Module -Name VMware.PowerCLI -RequiredVersion 12.5.0.19195797
Далее найдя нужный модуль, установим его, выполните команду.
Install-Module -Name VMware.PowerCLI
Еще можно объединять команды:
Find-Module -Name VMware.PowerCLI -MinimumVersion 12.5.0.19195797 | Install-Module
Начинаем исследование
На первый взгляд синтаксис командной оболочки кажется немного запутанным, но
в действительности все понятно и логично. Названия командлетов
стандартизированы, имена выглядят как «действие-объект». Так, чтобы получить
данные объекта, используем действие «Get-*», установить «Set-*», остановить –
«Stop-*», вывод – «Out-*» и т.д. Список всех доступных команд можно просмотреть,
выполнив «Get-Command». Для получения помощи набираем «Get-Help». К примеру,
просмотрим список процессов, рассортируем их по использованию процессорного
времени в убывающем порядке и выберем 10 самых прожорливых:
Все просто! Попробуем потушить самый жадный до CPU процесс:
Чтобы узнать, какие диски доступны, вводим:
Обрати внимание, что в списке будут присутствовать и ветки реестра HKCU и
HKLM, к которым можно обратиться как к обычному диску:
Теперь можно перемещаться по выбранной ветке, просматривать, создавать и
удалять объекты. Для PowerShell разработано большое количество
командлетов, и если ты не хочешь повторно изобретать колесо, вполне естественно
посмотреть на результаты работы других администраторов. Сообществом
PowerShell создан репозитарий командлетов
PoshCode Cmdlets, который является неким аналогом Perl CPAN. Здесь можно
найти решения практически на все случаи. Например, нужен снифер на PowerShell?
Нет ничего проще!
Качаем с сайта файл Get-Packet.ps1 и запускаем:
Все параметры описаны внутри файла. Другой командлет
Analyze-Packet позволит получить детальную статистику по пакетам.
По умолчанию выполнение сценариев в PowerShell запрещено, поэтому не
все команды удастся запустить. Просмотреть текущий статус политики выполнения
можно командой:
Существует четыре типа политики:
- Restricted — возможно выполнение отдельных команд, сценарии запрещены;
- AllSigned — разрешено выполнение подписанных сценариев, перед запуском
запрашивается подтверждение; - RemoteSigned – похож на предыдущий, не запрашивается выполнение сценариев,
подписанных надежным издателем, не требуется подпись для локальных сценариев; - Unrestricted – можно запускать неподписанные сценарии.
Удаленное использование модуля с другого компьютера
Вам никто не мешает создать некий такой репозиторий модулей PowerShell на отдельной виртуальной машине и обращаться к ним удаленно. Установим для начала сессию с удаленным компьютером.
$session = New-PSSession -ComputerName w10-module
Удостоверимся, что на удаленном сервере есть нужные нам модули, через команду:
Get-Module -PSSession $session –ListAvailable
импортируем теперь в свою текущую сессию нужный модуль с удаленного сервера:
Import-Module -PSsession $session -Name VMware.PowerCLI
После завершите сеанс, когда закончите:
Remove-PSSession $session
Еще можно использовать командлет Invoke-Command. Тут вы подключаетесь к удаленному серверу и импортируете модуль.
$session = New-PSSession -ComputerName w10-module Invoke-Command {Import-Module VMware.PowerCLI} -Session $session
Сохраним на локальный компьютер нужный нам модуль.
Export-PSSession -Session $s -CommandName *-PowerCLI* -OutputModule RemSQLServer -AllowClobber
Данная команда создаст на вашем компьютер новый PowerShell модуль VMware.PowerCLI (в каталоге C:\Program Files\WindowsPowerShell\Modules ). Сами командлеты при этом не копируются. Далее закройте сессию.
Remove-PSSession $session
Теперь его можно локально импортировать и использовать.
Экспортируем пользователей AD при помощи PowerShell в отдельный файл
Для начала вызовем справку для команды Get-ADUser. В результате Вы получите все необходимые команды для дальнейшего администрирования.
Help Get-ADUser – команда для вызова справки
Чтобы получить в окне PowerShell список всех пользователей со всеми свойствами, необходимо выполнить следующую команду:
Get-ADUser -filter * – экспорт списка пользователей AD
Данная выгрузка не совсем информативна и не умещает в окне всю необходимую информацию. Поэтому попробуем сузить поиск и выведем свойства конкретного пользователя с именем user1:
Get-ADUser -identity user1 -properties * – экспорт свойств определенного пользователя
А теперь попробуем экспортировать список всех пользователей с их свойствами во внешний txt или csv файл:
Get-ADUser -filter * -properties * | Export-csv -path c:users.csv -encoding Unicode – экспорт пользователей в отдельный файл
Хотелось бы обратить отдельное внимание на ключ -encoding Unicode. Он служит для того, чтобы русская кириллица, после экспорта из AD, могла корректно отображаться в выгруженном файле
Например, через Microsoft Excel мы увидим вопросительные знаки вместо русских букв.
При просмотре файла данные экспортируются в одну строку и тем самым не пригодны для чтения. Чтобы это изменить, нам необходимо выполнить следующие действия:
- Выделяем в Экселе первый столбец, как показано на скриншоте.
- Откроем вкладку данные > Текст по столбцам. И в окне мастера выберем параметр – С разделителями.
- В следующем окне выберем в качестве разделителя Запятую и нажмем > Далее.
В итоге получаем вполне себе читаемый csv файл, в котором каждое свойство пользователя разбито на отдельные столбцы.
Знакомство с PowerShell
Запустив PowerShell, вы не обнаружите поначалу никаких различий между ним и cmd.exe (разве что цвет фона окна у PowerShell по умолчанию — синий). Более того, вскоре вы обнаружите, что операции копирования/вставки в PowerShell реализованы также безобразно, как и в cmd.exe. Но первое впечатление о схожести этих оболочек, скажем так, не совсем соответствует действительности.
То обстоятельство, что работа оболочки PowerShell основана на .NET Framework, является главным ее отличием от предыдущих командных оболочек Windows. PowerShell полностью объектно-ориентирована. Результатом выполнения команды в PowerShell является не некий «текст сам по себе», а объект платформы .NET. Этот объект представляет собой собственно данные и имеет набор присущих ему свойств и методов.
Внутренние команды (точнее, командные структуры) для работы с объектами в PowerShell называются командлетами. Для них придумано специальное единообразное именование в виде комбинации действие-цель. Например, для получения данных используется действие “set”, для получения – “get”, для вывода — “out” и т. д. Цель – это тип объекта, к которому будет применено действие. Командлеты можно рассматривать как мини-программы, исполняемые в среде PowerShell. Для повышения функциональности можно создавать собственные командлеты или устанавливать командлеты сторонних разработчиков. Кроме командлетов, PowerShell позволяет выполнять функции, внешние сценарии (хранятся в файлах с расширением ) и внешние исполняемые файлы.
В состав PowerShell включена довольно обширная справочная система. Для начала работы с ней можно выполнить команду .
Для получения детальной справки по какому-либо командлету или разделу основных сведений, необходимо указать его название в качестве параметра команды.
Настройка времени
Как установить и изменить время в Windows
Способ 1
Пожалуй, наиболее очевидный и простой способ сделать это (в любой версии Windows) — щелкнуть правой кнопкой мышки (ПКМ) по отображаемому времени в правом нижнем углу экрана (), и в появившемся меню выбрать «Настройка даты и времени».
Настройка даты и времени (Windows 10)
После снять ползунки с автоматического определения времени и часового пояса и задать их вручную (особенно это полезно в том случае, если компьютер постоянно не подключен к интернету).
Текущая дата и время — Windows 10
Уточнение времени
Способ 2
Это универсальный способ! Сначала необходимо нажать на сочетание Win+R (появится окно «Выполнить») и использовать команду timedate.cpl. См. пример ниже.
timedate.cpl — настройка времени
Должно открыться окно настроек даты и времени — кликните по кнопке «Изменить…». После обновите необходимые вам данные…
Изменить дату и время
Способ 3
Если в Windows время изменить не получается (или она еще и не установлена даже ) — это можно сделать и через настройки BIOS (UEFI).
Как правило достаточно на основном (на первом) экране UEFI кликнуть по значку времени и установить то значение, которое вам нужно (я обычно раньше всегда ставил на +10 мин., чтобы никуда не опаздывать ).
BIOS (UEFI) — изменение времени
Теперь время будет спешить на 10 мин.
Как настроить синхронизацию (или отключить ее вовсе)
И так, для начала нужно использовать сочетание Win+R, и в окно «Выполнить» ввести команду timedate.cpl, нажать Enter.
Далее проверить свой часовой пояс (и уточнить его, если он установлен некорректно).
Изменить часовой пояс
Далее перейти во вкладку «Время по Интернету» и открыть окно изменения настроек.
Время по интернету — изменить
Далее установить галочку «Синхронизировать с сервером времени в Интернете», указать сервер и нажать OK (разумеется, если синхронизация у вас работает некорректно — лучше тогда снять эту галочку… ).
Синхронизация
Есть еще один универсальный способ отключить синхронизацию
Для этого необходимо открыть службы (сочетание Win+R, и команда services.msc ()).
Открываем службы — services.msc (универсальный способ)
В списке служб нужно найти «Службу времени Windows» и открыть ее.
Служба времени Windows
После перевести ее тип запуска в режим «отключена» и остановить ее работу. После этого синхронизация времени выполняться на ПК не будет!
Остановить!
Как изменить отображение: только часы и минуты, или дни недели с датой
В Windows можно немного по-разному представить отображение времени: с датой, с днями недели и пр. (см. скрин ниже, я спец. сделал 3 разных варианта).
Кстати, рекомендации ниже актуальны для ОС Windows 10…
Как отображать время в трее
Для настройки отображения:
-
сначала необходимо нажать Win+R (для вызова «выполнить»), и воспользоваться командой intl.cpl;
- далее открыть доп. параметры, и в разделе «Дата» и «Время» поменять формат на тот, который нужен вам (более подробно можете почитать здесь).
Как изменить отображение даты (времени)
Да, кстати, чтобы в Windows 10 отображалось не только время (но и дни недели, дата) — необходимо зайти в параметры ОС (Win+i) и в разделе «Персонализация / Панель задач» отключить использование маленьких кнопок на панели задач (эта штука на некоторых ноутбуках вкл. автоматически).
Использовать маленькие кнопки панели задач
Что делать, если время сбрасывается (слетает)
Причина 1
Наиболее частая причина сброса времени — это севшая батарейка на материнской плате компьютера (в среднем одна добротная батарейка живет ∼5-7 лет). Что характерно при этом: время слетает после отключения/перезагрузки ПК (в процессе работы — должно быть всё нормально…).
Как выглядит батарейка на мат. плате
Приобрести новую батарейку можно практически в любом компьютерном магазине (и даже заказать в Китае ).
Причина 2
Неправильно установленный часовой пояс. Из-за этого Windows при любых обновлениях устанавливает автоматически некорректное время.
Если авто-режим неправильно определяет ваш пояс — задайте его вручную (для Windows 10: сочетание клавиш Win+i —> Время и язык —> Дата и время —> Часовой пояс ).
Часовой пояс — Windows 10
Еще один вариант: сочетание Win+R — > команда timedate.cpl
Изменить часовой пояс
Причина 3
Дело также может быть в некорректной работе синхронизации (например, из-за каких-то системных сбоев ОС, или неправильно-установленного часового пояса, или, например, из-за использования устаревшей версии Windows (от народных «умельцев»)).
Чтобы исправить подобную проблему: уточните часовой пояс и измените . Если не поможет — отключите синхронизацию и установите время вручную (как это сделать — см. чуть выше в статье ).
Разумеется, по теме — только приветствуются!
Всего доброго!
Переменные окружения
Через Powershell можно устанавливать и читать переменные окружения. Обычные методы позволяют изменять значения окружения только на текущую сессию, но вы можете использовать методы .NET, которые могут создать постоянные значения.
Значения, которые вы можете установить в переменных окружения, могут быть только строками. Создать массивы, числа и функции вы не сможете. Плюсы этого метода в том, что они будут доступны для любого интерпретатора и программы.
Чтение
Для получения переменных окружения вы можете использовать 2 способа. Первый — через встроенную переменную $env. Так это будет выглядеть на примере переменной Path:
Еще один способ заключается в том, что в Powershell переменные окружения располагаются как отдельный раздел в который вы можете перейти и вывести все значения:
Открыть значение любой переменно можно так же как и любой другой файл:
Переменные окружения делятся на несколько типов: machine -> user -> process, .
- machine — относится к ОС и эти переменные может прочитать любой пользователь;
- user — относятся к конкретному пользователю. Эти значения перезаписывают значения machine;
- process — динамические переменные, которые создаются при запуске процесса. Они являются совмещением user + machine.
Используя способы выше вы видите только динамические переменные. Если у вас есть 2 одинаковых переменных на пользовательском и системном уровне вы можете использовать метод .NET для получения конкретной переменной:
Либо вы можете все переменные окружения конкретного типа:
Создание
Переменную окружения, которая будет жить в рамках одной сессии Powershell, можно создать следующей командой:
При закрытии консоли, переменна созданная выше, будет удалена. Исправить это можно использовав методы .NET. В следующем примере мы создадим переменную типа «Machine», но уже постоянную:
Аналогичное действие, но для пользовательских переменных:
Изменение и удаление
Изменить переменную окружения, на текущую сессию, можно следующими способом:
Что бы сделать изменения постоянными нужно использовать метод .NET:
…
Рекомендую
Работа с реестром
При выполнении различных настроек и попытках обнаружения каких-либо параметров нам иногда приходится обращаться к системному реестру в поисках ключей, значений и т.п. С использованием возможностей Windows PowerShell эта задача может быть решена достаточно простым способом. Возможности Windows PowerShell показаны на рис. 14.
Наша первая команда использует алиасsl
для выполнения команды set-location
, изменяющей наше текущее местоположение с файловой системы на ветвь HKEY_CURRENT_USER в системном реестре:
PS C:\> sl hkcu:
Отметим, что, как и в случае работы с файловой системой, PowerShell применяет специальный провайдер для доступа к реестру.
Аналогами приведенной выше команды являются команды:
PS C:\> sl registry:hkcu
PS C:\> sl hkey_current_user
Следующая команда загружает содержимое всей ветви реестра HKEY_CURRENT_USER в переменную reg:
PS HKCU:\> $reg = gci . –rec –ea silentlycontinue
Для этого мы используем команду get-childitem
(алиас — gci
), принцип работы которой аналогичен работе с файловой системой. Первый аргумент этой команды — «.» — указывает на то, что мы хотим получить содержимое текущей ветви реестра — HKEY_CURRENT_USER. Второй аргумент является сокращением от опции –recurse
и указывает на то, что нам нужен рекурсивный сбор данных из всех подветвей текущей ветви реестра. И наконец, третий аргумент — –ea silentlycontinue
— указывает на то, что команда должна продолжать выполняться даже в случае возникновения ошибок, связанных с недостатком прав доступа к определенным подветвям реестра.
Следующая команда в нашем примере:
PS HKCU:\>$s = $reg | % {if (gp $_.pspath) –match ‘PowerShell’){$_.pspath}}
копирует из реестра данные, содержащие строку ‘PowerShell’
. Мы начинаем с того, что берем объект reg
и перенаправляем его в команду %
, которая является алиасом команды for-each
. Она выполняет рекурсивный обход всех элементов реестра, находящихся в объекте reg
и на каждом шаге сохраняет элемент в специальном объекте PowerShell с именем ‘_’
. В фигурных скобках мы указываем действия, которые должны выполняться на каждом шаге выполнения команды for-each
. Внутри блока for-each
мы используем проверку if
для того, чтобы узнать, соответствуют ли текущая запись реестра и ее свойство pspath, которые мы получаем через обращение к команде get-itemproperty
(через алиас gp
), нашему критерию — наличию строки ‘PowerShell’
. Если соответствие найдено, мы возвращаем значение свойства pspath
. Все найденные соответствия сохраняются в объекте s
.
Работу с реестром мы завершаем перенаправлением результатов поиска в команду select-object
(через алиас select
) и показываем два первых найденных результата. В качестве упражнения вы можете перенаправить финальные результаты в файл с помощью команды out-file
.
Создание временного файла
Командлет: New-TemporaryFile
В скриптах нередко нужно создать временный файл, чтобы скинуть туда какую-то информацию. Новый командлет создан именно для этого.
#Создание временного файла New-TemporaryFile #Создание временного файла и получение его полного пути $tmpfile = (New-TemporaryFile).FullName $tmpfile
При создании CheckBootSpeed у меня была именно такая задача – записать собранные данные во временный файл, показать его в блокноте и удалить. Командлета не было, но Василий Гусев подсказал такой вариант:
$file = ::GetTempFileName()
Здесь обратный случай – командлет легче запомнить, чем класс .NET. В утилите я сейчас такой способ не использую, но на заметку взял.
Enumerating User Profiles
It’s easy to take a peek at user profiles on the file system on a single Windows computer. Simply look in the C:Users folder. However, when you do this not only are you not getting the full picture, it’s also troublesome due to potential file system access problems. There’s a better way and that’s through WMI.
In WMI, a class exists called Win32_UserProfile. This class contains all of the profiles that exist on a machine and lots of other useful information that a simple file system folder won’t show you.
Using PowerShell you can access this WMI class with the Get-CimInstance or Get-WmiObject cmdlets. In Figure 1 below, we’re finding the first user profile on the local computer. You’ll notice many useful tidbits of information like LastUseTime, SID and from here, you can also drill down further and get specific paths like Desktop, Documents, Favorites, etc.
Since this is part of WMI, we can easily extend this from a single computer to many computers using the ComputerName parameter. In order to be compatible with down-level operating systems, we can use the Get-WmiObject cmdlet here to enumerate user profiles on the MEMBERSRV1 and CLIENT2 computers.