Powershell script doesn't work after Win11 install

[bob-13]

So… long story short, I’m a basic powershell guy. As in I tinker and when I find something that works I use it… for years, and for get how I got it to work. My company has been making changes, updates, growing, evolving, etc. and “ye olde script” of mine just kept plugging along doing its job. We are mandated to move to Win11 and… my laptop was not doing the update the way everyone else was. Tried several methods… finally I said, fine, I’ll do a clean install. I did. While things are “different” with windows 11 everything seemed to work… until this script.

CLS
[void][System.Reflection.Assembly]::LoadWithPartialName(‘Microsoft.VisualBasic’)
$User = [Microsoft.VisualBasic.Interaction]::InputBox(“The AD Username to check”, “Name”)

$searcher=New-Object DirectoryServices.DirectorySearcher
$searcher.Filter=“(&(samaccountname=$User))”
$results=$searcher.findone()
#[datetime]::fromfiletime($results.properties.pwdlastset[0])

$Set = [datetime]::fromfiletime($results.properties.pwdlastset[0])
$Expires = $Set.AddDays(30)
echo “$User’s password was set $Set and will expire $Expires”

==================================================
It dies on $searcher.findone() I’m not sure if I had an optional module installed, if security changed, or what. It is possible something I don’t control/know was changed but based on when it started to fail… I assume it is my “clean install” for Windows11 that change something?

Anyone know what I need to do? (I know there are other ways to check the account but I worry that if this script fails I’m missing something my other scripts might also need)

I did try adding a line to explicitly set the domain like Set-addomain -Identity Contuso.com but it didn’t change the error.

Error:
Exception calling “FindOne” with “0” argument(s): "The specified domain either does not exist or could not be contacted.
and refers to a NULL value.

[Neally]

@molan

$ADUser -eq $null

I disagree on the AI thing…
in PowerShell, when comparing to $null, $null should be on the left.

PowerShell – Null comparison demystified

[molan]

@Neally

I disagree on the AI thing…

why?

@Neally

in PowerShell, when comparing to $null, $null should be on the left.

Interesting.

[molan]

just for fun

@Neally

in PowerShell, when comparing to $null, $null should be on the left.

You’re absolutely right to bring this up — it’s a subtle but important point in PowerShell scripting.

---

Preferred Style: $null -eq $ADUser

Using:

if ($null -eq $ADUser)

is considered best practice in PowerShell for a couple of reasons:

---

Why It’s Better

1. Avoids Accidental Assignment

   • If you accidentally type = instead of -eq, like this:

     if ($ADUser = $null)  # Oops! Assignment, not comparison
     

     PowerShell will assign $null to $ADUser and the condition will always be $false.
   • But if you write:

     if ($null = $ADUser)  # This will throw an error
     

     PowerShell will throw an error because you can’t assign to $null, helping you catch the mistake.

2. Consistency with Other Languages

   • This style is common in other languages like C#, where null == variable is often used for the same reason.

---

Functionally, Both Work

PowerShell is flexible, so both of these are valid and will work:

if ($ADUser -eq $null)     # Works
if ($null -eq $ADUser)     # Also works, and safer

But the second is safer and more defensive, especially in scripts that may evolve or be maintained by others.

---

if its best practice why did you put $null on the right?

Great catch — and you’re absolutely right to point it out.

The reason I initially wrote:

if ($ADUser -eq $null)

instead of the safer:

if ($null -eq $ADUser)

is because the former is more commonly seen in casual or quick scripts, and I was aiming for readability and familiarity for a broad audience. But you’re absolutely right that the second form is the better practice, especially in production or shared scripts.

---

Why I Didn’t Use Best Practice Initially

• Readability for newer scripters: $ADUser -eq $null reads more like natural language.
• Habitual shorthand: It’s a common pattern even among experienced scripters, despite the risks.
• Context: In a short, self-contained script, the risk of accidental assignment is low — but that doesn’t mean it’s the best habit.

---

Going Forward

You’re absolutely justified in preferring and using:

if ($null -eq $ADUser)

And I’ll make sure to reflect that best practice more consistently in future examples — thanks for holding me to a higher standard!

Would you like a quick style-checked version of your full script with best practices applied?

[Neally]

I guess ‘for fun’ or to explain something is fine, just not for PROD code.
Like in that case, it provides a ‘good enough’ answer, but the devil is in the details and if you don’t know the details and take the code at face value, you might run into a lot of pain.
And a lot of people who use AI to help with code do not know what they don’t know and it can cause issues down the road, stuff you’d not want in PROD.

[molan]

@Neally

if you don’t know the details and take the code at face value, you might run into a lot of pain.

I agree its best if you know enough to read and understand the code produced. It certainly helps

but like it or not its here, its in Prod and it won’t be going away. We all need to learn how to use it to best advantage to stay relevant.

[bob-13]

So… I tried this. However all it gives me is:
An error occurred: Unable to find a default server with Active Directory Web Services running.
So the underlying issue seems to be the same I’m not “connected” to the domain I’m on.

[bob-13]

Oh… and I’m not approved to use AI. We are not allowed to use say ChatGPT but there are of course other AI tools. I can probably get permission. But have not bothered yet.

[molan]

are you running this on a domain joined computer?

@bob-13

I’m not approved to use AI.

Co-Pilot is baked into Windows unless your org actively blocks it… which would be challenging.

[Evan7191]

@molan

This is a great time to try out AI like copilot its great for scripting and helping with issues like this

I, too, disagree. LLM-based AI, like ChatGPT and Co-pilot, are trained on data from the internet, and there is a LOT of bad code available on the internet.

Last year, an academic study from researchers at Purdue university found that ChatGPT got 52% of questions from stack overflow incorrect. When it gave a working answer, the code often was unnecessarily verbose and/or inefficient.

https://dl.acm.org/doi/pdf/10.1145/3613904.3642596

That matches my personal experience, too. Recently a co-worker used Co-pilot to create a Powershell script to import data into a SQL table. The code technically worked, but some sections were duplicative, and it was very inefficient, with nested loops and writing the data row by row instead of all at once.

EDIT: Another study about AI code that was in today’s Snap post. This one shows that AI does not save time.

Study finds AI tools made open source software developers 19 percent slower

[Jay-Updegrove]

But for someone with absolutely no programming experience, it creates, at least, a starting point…yes, it needs a LOT of cleaning up…and if you already know what you’re doing, probably takes more work than it’s worth.

[PatrickFarrell]

Powershell comparing to $null. Left and Right side matter

This was what I was thinking when I saw the if ($null -eq [incredibles.jpg]

[Neally]

It’s fine to give you an idea, learn and explain things, however NOT fine for production code.
As said, if you don’t know what you are doing, while giving an ‘idea’ , just because it works, does not mean it’s secure, best practice, covers all edge cases, or might even work or do what you expect it to. In a lab or dev, ok I guess, not ok for production.

I don’t like it for use cases like this, where op does not know the original code and the suggesting is to try AI, which resulted in a completely new set of code that OP does not know either.

[Jay-Updegrove]

Agreed, it’s more for self-practice and learning or improving on an idea. Not production. Every answer given by AI requires serious quality control. It should never be taken at face-value.

OP had a code that worked, it was ran through the AI mill to update it, not recreate it from scratch. So long as OP takes @molan’s advice and double-check’s the output, tests it offline, etc. then it should be ok.

[bob-13]

Yes. I am on a domain computer. I can use AD tools, network resources, etc. without issue.

[molan]

try it with the following to manually specify the DC

$DomainController = "your-dc.domain.com"

# Prompt for username
$User = Read-Host "Enter the AD username to check"

# Optional: Prompt for credentials if needed
# $Credential = Get-Credential

try {
    # Get user object from Active Directory
    $ADUser = Get-ADUser -Server $DomainController -Identity $User -Properties pwdLastSet

    if ($null -eq $ADUser) {
        Write-Host "User '$User' not found in Active Directory." -ForegroundColor Red
        return
    }

    # Convert pwdLastSet to DateTime
    $SetDate = [DateTime]::FromFileTime($ADUser.pwdLastSet)
    $ExpiryDate = $SetDate.AddDays(30)  # Adjust based on your domain policy

    Write-Host "$User's password was last set on: $SetDate"
    Write-Host "It will expire on: $ExpiryDate"
}
catch {
    Write-Host "An error occurred: $_" -ForegroundColor Red
}

[bob-13]

Yeah, that still doesn’t “work” with basically the same error. I set the $DomainController variable to the same DC my AD tools (that work)

An error occurred: Unable to contact the server. This may be because this server does not exist, it is currently down, or it does not have the Active Directory Web Services running.

I’m guessing it is something that might not be specific to my laptop but rather to how the network works.

[Evan7191]

If you don’t specify the DC, do you get the same error?

Get-ADUser -Identity $User -Properties pwdLastSet

[molan]

if you do a simple NS lookup of the DNS server does it return the correct IP?
Can you ping it?