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!

Hi Folks!

Here is a quick tip to install the VMware PowerCLI, which is – like the name says – for Windows PowerShell.

To initiate the installation process, type this command into the Powershell Console:

Install-Module -Name VMware.PowerCLI

Powershell will ask you if you wish to install “NuGet”, which is required to automatically download and install VMware PowerCLI from PSGallery. You also have to trust the PSGallery repository in order to proceed with the installation.

Now you can list all of the VMware PowerCLI Modules:

Get-Module -ListAvailable | where { $_.Name -match “vmware” }

Or just check your currently installed VMware PowerCLI version:

Get-PowerCLIVersion

Enjoy!

With Windows Server 2008 R2, Active Directory has now a recycle bin. With this feature you do not have to use for example Windows Server Backup to initiate an authoritative AD restore, instead you can quickly recover deleted Users, OUs, Groups and other objects through Active Directory Administrative Center (Windows Server 2012 an upwards) or PowerShell

Enabling AD Recycle Bin (PowerShell commands

Enable-ADOptionalFeature ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target ajni.lab

Type A (=Yes to All) to enable the feature

(Optional) Check Deleted Object’s Lifetime

Get-ADObject “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ajni,DC=lab” -Property msDS-DeletedObjectLifetime | fl

If you do not see the Property named “msDS-DeletedObjectLifetime”, it means that it has the default value of 60 days.

You can change is with this command – do not forget to replace DC=ajni, DC=lab with your domain name:

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=ajni,DC=lab” -Partition “CN=Configuration, DC=ajni,DC=lab” -Replace:@{“msDS-DeletedObjectLifetime” = 120}

Checking the property again, you‘ll see your new value:

You can also have a look at this property with ADSIedit:

Restoring an Object

In our example we deleted an OU called “ImportantOU”

Let’s list all Deleted Objects:

Get-ADObject -filter ‘isdeleted -eq $true -and name -ne “Deleted Objects”‘ -includeDeletedObjects

And then restore our important OU. Before Restoring we can check if the Filter finds our OU:

Get-ADObject -Filter ‘msDS-LastKnownRDN -eq “ImportantOU”‘ -IncludeDeletedObjects

Now restore:

Get-ADObject -Filter ‘msDS-LastKnownRDN -eq “ImportantOU”‘ -IncludeDeletedObjects | Restore-ADObject

Our important OU is back from the dead:

We can also restore from Active Directory Administrative Center (ADAC)

Note that while AD Recycle Bin gives you the flexibility of quickly restoring deleted AD Objects, you should also have a functional Windows Server Backup and VM Backup with solutions like HPE Data Protector or VEEAM. Just in case something goes horribly wrong!