Query - Powershell Script to Check a Single User AD Account and Unlock if required - Formatting Question

Hi All,

I have the below working script, though would like to pick some experts brains please.

A)Is there anything wrong, i.e, can I cause harm/damage if I am running the "Unlock-AD" if the actual account isn't even locked?

eg, should it include something like - If Username is locked, then Unlock?

B)Is the below formatting OK, or is there a better "Preferred/Recommended" way I should be using?

C)As I work in 1st/2nd Line Support I often get calls for AD unlocks, any other suggestions I should be running this script to make it more efficient

eg, does anyone use a script to search for surname and first name to pick up female name changes etc instead of by username or how else do others do their environment?

Thanks,

************************************************

Import-Module ActiveDirectory

$Credentials = Get-Credential $UserName = Read-Host "Enter in the Username to check"

Get-ADUser $UserName -Properties Displayname, LockedOut, badPwdCount, AccountLockoutTime, PasswordExpired `

| Select-Object -Property Displayname, LockedOut, badPwdCount, AccountLockoutTime, PasswordExpired

unlock-ADAccount $UserName -Credential $Credentials

************************************************

  • BTW, What is the secret to getting the SourceCode formatting to work, When ever i use the 'SourceCode" method on this site it doesnt seem to make any difference. Thanks,
  • You should always check the current state / content of things before acting on them as a best practice.
    No real need to take action on something that is already correct.

    Formatting is a matter of preference. There are practice guidance out there and some follow them and some don't.
    You have to choose what makes sense to you and to those who will follow you or to those whom you will share your code.

    I have my standard approach and dome of my ways others would potentially not agree on and there are approaches that others state that I don't agree with.

    All-in-all pick your way of doing business. If you are new, then follow the documented practices, until you find your groove to a pattern you really like. DO not take every practice as a blanket, 'you have to do it this way', because it's not a valid statement. There are many places where you have to do X or Y a certain way, but there are just as many places where there is choice / flexibility.

    Again, you can read and see many coding styles, from MS, the PowerShell MVP's out there, but again, it is about choice.

    To get you started, just look at the source code of any of the built-in PowerShell cmdlets / modules / help files as your starting point.

    But coding practices have and will always be influenced by experience form other programming languages or the document you are following or the speaker you will listen to.

    'Use your favorite search engine to find them'
    'PowerShell code best practice'
    'PowerShell do's and don'ts
    'PowerShell Annoyances'
    'PowerShell Script best practice'
    'PowerShell module best practice'
    etc...

    I constantly read and listen to others, and always walk away with ideas to make thing better in my day to day.
    I also walk away with many WTH moments. Meaning, an article/speaker/instructor etc.. 'why are they / doing-did they do it this / that way'

    Full disclosure. I have been in IT since 1977 (computer operator, programmer, Database admin / architect, solutions architect, engineer, developer, security specialist, datacenter, cloud, mobile, business own etc.) and I've seen a lot of crap and really good stuff. I do what works for me, regardless of other opinions, but I have a pattern and I stick with it.

    BTW, there are also, what are called 'Code Beautifiers'...

    'Use your favorite search engine to find them'

    ... that can be leveraged. Meaning write your code then use a CB to format it pretty. Visual Studio Code, which can almost replace the PowerShell ISE (almost), has many add-on for this sort of beautifying thing.