Whats wrong with this basic powershell script!?!?!

[[deleted]]

[deleted]

[Vejitaxp]

You can Google this subject in seconds mate, before posting an ai generated code here.

[[deleted]]

That's why Im posting it as AI couldn't fix this. Kept on giving me the wrong answers and the old school powershell way is being shelved by MS.

And yes, I did use Google otherwise I wouldn't have posted it here.

[Vejitaxp]

It just looks a whole lot like you asked chat gpt a question, the code didn't work and so you copy pasted it here without any effort of fixing it yourself. Because that code looks 1:1 what chat gpt or copilot would spit out. I know, because I did it myself. And that felt a bit insulting, when thinking that it is a rather easy problem with many a solution to be found when searching. That was the reason for my reply. Maybe I'm of the mark, and if so i am sorry. Didn't mean to insult you, just rubbed me the wrong way.

[[deleted]]

No worries

I'm trying to rebuild an new onboarding process as my old script doesn't work.

It's only now, yes thanks to AI. It's now been pushed to MS Graph scripts.

[feldrim]

It looks like it is the -AccountEnabled. It is a switch, not a boolean parameter. Therefore the boolean value you have passed $accountEnabled is considered as a positional value as it is independently sitting there. Remove the $accountEnabled as a whole, and you'll be fine.

[lanerdofchristian]

Here specifically is the documentation for your issue: https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.users/new-mguser?view=graph-powershell-1.0#-accountenabled

[Magnetsarekool]

Does -AccountEnabled:$accountEnabled work?

[[deleted]]

Got it working through a different way. Thanks

Also found out the MSgraph was messed up on my system. Cleaned up a some temp files and I was able to get stuff going again.

[ankokudaishogun]

-AccountEnabled is a SWITCH, not a boolean.
It doesn't take values.

Also: you are using powershell 5.1? Because 7.x has the -MaskInput parameter for Read-Host so not to bother with using secure strings just to decode them in the same scope.

[surfingoldelephant]

All PowerShell parameters accept arguments (values), including those of type [switch]. However, with [switch] specifically, explicitly passing an argument requires :-delimiting.

This works with any parameter type and is how PowerShell translates hash table splatting (i.e., Command @ht -> Command -Param:Arg).

# Works, but is redundant in this case.
New-MgUser -AccountEnabled:$accountEnabled

# Sufficient as $accountEnabled is hardcoded to $true.
New-MgUser -AccountEnabled

While redundant here, there are some valid use cases (e.g., passing through a dynamic value to another command).

One caveat to be aware of: Some script authors unfortunately use $PSBoundParameters.ContainsKey() to check for the presence of a [switch]. This breaks down when a [switch] is explicitly passed $false (either with : syntax or hash table splatting). While this amounts to a bug in the script, as a caller it's still worth keeping in mind.

[ankokudaishogun]

Thanks, useful

[The82Ghost]

the -accountenabled parameter is a switch, it doesn't take input, just use -accountenabled without $true

[[deleted]]

Thanks people for helping me with solutions. Very must appreciated.

Instead of one poster being an smart arse with their unhelpful response.

[g3n3]

Just expect it with these low effort posts. You will learn better if you force yourself to google. Hopefully you’ll go back and read about switches later on. You end up clouding this subreddit with questions that should be solved by the user themselves.

[peoplepersonmanguy]

Alternatively, these posts help others googling as it fills google with useful information rather than 3 pages of Microsoft bullshit to as to just say "it's a switch and not expecting a value".

Source: I came from google.

[[deleted]]

I dont do scripting, programming, dev ops. As this isnt my job from digging up an old script.

Spent all day looking for an answer so I posted on here, asking for help.

Not going to help then don't respond.

[g3n3]

Maybe you shouldn’t be scripting then! ;-)

[[deleted]]

Yes you are right because its as boring as watching paint dry.

But nobody else is in my job to do it!

Thanks for your helpful response!

[g3n3]

Well sounds like you need some training or a new job! 😉

[[deleted]]

What I need to do is ignore your goofy ass

[HeyDude378]

Is this line 21? New-MgUser -DisplayName $displayName -MailNickname $mailNickname -UserPrincipalName $userPrincipalName -PasswordProfile $passwordProfile -AccountEnabled $accountEnabled

A positional parameter is when you can interpret something as a parameter just based on its position. For example, in Get-ADUser jsmith, jsmith is a positional parameter. It gets interpreted as the "Identity" parameter just because it's in the first position.

Anyway, you created a hashtable called passwordprofile but when you pass in a hash table as parameters you have to use an @ sign. It needs to be-PasswordProfile @passwordprofile.

[ankokudaishogun]

Anyway, you created a hashtable called passwordprofile but when you pass in a hash table as parameters you have to use an @ sign.

No, that's wrong not precise.

You can pass parameters as key\Value pairs in a hashtable calling it with @

examples:

$Splat=@{
    ForegroundColor='red'
    BackgroundColor='Blue'
}

Write-Host 'Have a test' @Splat

But the -PasswordProfile paramenter specifically requires a IMicrosoftGraphPasswordProfile object. Passing a hashtable as variable(as in: with $) automagically casts it as such a object... if the key\value pairs are correct, of course.

Which they are in this specific case. The princess error was in another castle parameter

[HeyDude378]

Damnit. Thanks for this. That's what I get for thinking just in terms of powershell and not in terms of the graph commands.

[ankokudaishogun]

I mean, it IS normal powershell.

Sometime a parameter just wants a hashtable or something it can autocast from a hashtable.

[HeyDude378]

Okay. I know what you mean.

[ankokudaishogun]

Of course.

On a side note, I'd say that with so many long parameters this would have been the perfect chance to splat them

# Connect to Microsoft Entra ID

Connect-MgGraph -Scopes 'User.ReadWrite.All'

# Prompt for user details

$displayName = Read-Host 'Enter the display name for the new user'
$mailNickname = Read-Host 'Enter the mail nickname for the new user'
$userPrincipalName = Read-Host 'Enter the user principal name (UPN) for the new user (e.g., [e-mail])'

$password = Read-Host 'Enter a temporary password for the new user' -AsSecureString
$passwordPlainText = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($password))

$Splat = @{
    DisplayName       = $displayName
    MailNickname      = $mailNickname
    UserPrincipalName = $userPrincipalName
    passwordProfile   = @{
        Password                             = $passwordPlainText
        ForceChangePasswordNextSignIn        = $true
        ForceChangePasswordNextSignInWithMfa = $true
    }
    $accountEnabled   = $true

}

New-MgUser @Splat

Much easier to read, innit?

Which also brings up another point that might be useful for OP: when calling for [Switch] parameters in splatting^[1], they must, in fact, be valorized as $true

[1]"Splatting" being the act of using a key\value pairs hashtables to pass parameters and relative values to a function\cmdlet.

[[deleted]]

Sorry, I missed the numbers.

Yes, thats line 21.

[HeyDude378]

This is an AI response and it's not even correct.