If you ever need to copy NTFS permissions of a folder, there is a quick PowerShell one-liner that will save your day:
Get-Acl C:\SourceFolder| Set-Acl D:\DestinationFolder
Have fun!
Reading time: 1 min
If you ever need to copy NTFS permissions of a folder, there is a quick PowerShell one-liner that will save your day:
Get-Acl C:\SourceFolder| Set-Acl D:\DestinationFolder
Have fun!
If you are using Citrix MCS with Azure VMs, you might have noticed that not all the VM SKUs are available to select when creating a new Machine Catalog. With PowerShell, though, you can use any Azure VM SKUs.
If you are using Citrix Cloud, you have to download and install the Citrix Powershell SDK and login with your Citrix credentials. Optionally you could download an API client and authenticate with those credentials.
The secure client can be downloaded under Identity and Access Management > API Access > Create client. The customer id will also be shown on that page.
You authenticate with the API client this way:
Set-XDCredentials -CustomerId "customername" -SecureClientFile "C:\temp\secureclient.csv" -ProfileType CloudAPI
Otherwise, without API credentials, after executing the first command, you will be asked to insert your Citrix credentials:
Now the commands to change the Citrix MCS VM type.
Get-ProvScheme -ProvisioningSchemeName "CatalogName"
Take note of the folder name after XDHYP:\HostingUnits\ under MasterImageVM.
This command will register the virtual drive XDHYP:\ in PowerShell:
Set-HypAdminConnection
Insert that folder name in this command:
Set-ProvScheme –ProvisioningSchemeName "CatalogName" –ServiceOffering "XDHyp:\HostingUnits\Foldername\serviceoffering.folder\Standard_NV4as_v4.serviceoffering"
Delete and re-create the VM. The right VM type will be then used.
Saving credentials and secrets inside your code is a very bad idea and should be avoided. PowerShell has built-in commands to export and import encrypted data in your code.
There might be a lot of ways to achieve this, but this is how I like to do it. This is very elegant and easy to implement.
Let’s say we have a secret password that we want to secure and avoid saving in the source code.
$secretPW = "SecretPassword" | ConvertTo-SecureString -AsPlainText -Force
We can export this variable to an encrypted XML file with
$secretPW | Export-Clixml -Path .\secret.xml
The password is not human readable:
To import this file use
$secretPW = Import-Clixml -Path .\secret.xml
The plain-text password can be obtained through (I had to split the command into two lines)
[System.Runtime.InteropServices.Marshal]::
PtrToStringAuto([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secretPW))
Just outputting the variable won’t show the password, because the variable is a System.Security.SecureString object.
Credentials can also be saved this way:
$credentials = Get-Credential
You can show the plain-text password with
$credentials.GetNetworkCredential().password
$credentials | Export-Clixml -Path .\credentials.xml
Only the username is shown in clear text.
Same thing again with the import
$credentials = Import-Clixml -Path .\credentials.xml
$credentials.GetNetworkCredential().password
The password can be decrypted by the same user that created the XML file on that specific computer.
References:
https://devblogs.microsoft.com/scripting/decrypt-powershell-secure-string-password/
https://pscustomobject.github.io/powershell/functions/PowerShell-SecureString-To-String/
A quick post on how to change the Windows display language with Powershell. You might use these commands based on any logic that determines the user's location/language. For instance, I created a script that gets executed on logon and sets the language based on some criteria (maybe an Active-Directory group or attribute).
Set-Culture en-US
Set-WinSystemLocale -SystemLocale en-US
Set-WinUILanguageOverride -Language en-US
Set-WinUserLanguageList en-US -Force
Set-WinHomeLocation -GeoId 244
You can find the right GeoID on Microsoft's website
Hey folks!
Here is a quick way to find inactive AD Users in your environment. Get-ADUser ist the cmdlet we are going to use.
We are getting all users from the highest OU (domain.com) and using the Property LastLogonDate, which will not be returned if not specified in the -Properties parameter. After that a Where statement is going to show users that haven't logged in since 90 days or more.
Get-ADUser -Filter * -Properties lastlogondate | where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }
We could also specify the OU where the command is going to search:
Get-ADUser -Filter * -Properties lastlogondate -SearchBase "OU=TerminatedEmployees,DC=Company,DC=com"| where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }|select Name,Lastlogondate
There is also the -SearchScope Onelevel parameter to determine that we are not going to search recursively:
Get-ADUser -Filter * -Properties lastlogondate -SearchBase "OU=TerminatedEmployees,DC=Company, DC=com" -SearchScope OneLevel | where { $_.lastlogondate -lt (Get-Date).AddDays(-90) }|select Name,Lastlogondate
Have fun!