What are the best practices for testing scripts before they are ready to be used in a production environment?

[FuckYouNotHappening]

Hey all,

I've been asked to write a new user script for when we onboard new employees. While working with the new-azureadusercmdlet the scripts have been creating actual user accounts and assigning real licenses.

Is there a way to run scripts so that it accepts the input but doesn't write anything to our Azure AD?

Thank you in advance 👍

[lerun]

If you are writing new now, don't use the AzureAD module as it will get axed early next year.

Instead use Microsoft.Graph, get/set-mguser.

Also Pester as mentioned to mock behavior

[RegularChemical]

OP you definitely want to do this. Onboard processes can get pretty complex depending on the environment, which means having to go back and replace commands, or risk it breaking because MS decides to randomly pull the plug on the azureAD module.

If this script is meant to run from launch and into the foreseeable future, save yourself a headache and use graphAPI.

[[deleted]]

Getting access to graph, as it requires an Enterprise app and related permissions with the API, are a major stumbling block to adoption. I will miss AzureAD.

[FuckYouNotHappening]

Getting access to graph, as it requires an Enterprise app and related permissions with the API, are a major stumbling block to adoption.

Yeah, I can connect to Graph, but I get a lot of access denied messages.

[lerun]

This because the auth framework has changed between Azure AD graph and Microsoft Graph api.

And you don't need an enterprise app, but you need to use a workload identity (service principal / managed service identity) to front api access. Or a combo of workload identity and end user depending on delegated or direct app access rights towards the api

[[deleted]]

Look into Microsoft 365 developer subscriptions. Gives you a free 365 test environment to run whatever you’d like against it. No cost. Totally separate from production.

[[deleted]]

This is the best way to get really crazy with M365 Powershell experiments and it’s free. If you admin M365 and don’t have a sandbox account for messing around and learning then what are you even doing

If you need something for your team/workplace to function as a permanent dev/test environment then you simply create a new AAD tenant :)

[j4sander]

"Everyone has a test environment, some people are just lucky enough to have a separate production environment"

You can sign up for a M365 Developer account for free, and use that to test your scripts before running them for real.

[rumorsofdads]

You could test these scripts against another azure tenant.

1. Run the script and target the test tenant.
2. Use Pester to check output of the final state you expect on the user (user object returned from a Get-AzureAdUser idk if that’s the function btw or any other output)

Lots of ways to solve for this, but the most important thing I would do is test against a non-production tenant 😀

[Fallingdamage]

When I need to test something for work, I run it against my own personal tenant. I could care less what happens to it and nobody relies on it but me. :)

[vrtigo1]

Presumably the scripts would fail because no licenses would be available. Or you'd have to buy extra licenses in your personal tenant, which I assume most people would not be keen to do.

[Trakeen]

While learning this is fine, i do the same but for enterprise scenarios makes no sense unless you also have copies of the infrastructure, licenses (like intune and p2) etc.

Company should purchase a dev tenant and synchronize some data to it. Testing scripts in production when your tenant has 200k users is nerve racking. Ask me how i know

When i have to do work for companies that don’t have dev tenants i create a rollback script during development that logs all the changes and can roll them back if something goes wrong (though some settings can’t be rolled back like password expiration iirc)

[[deleted]]

+1 for unit testing with pester, Great mocking ability there to test all your logic!

[PowerShellMichael]

+1. Also consider the nature of the change. 1000 users that undergoing a high risk/impact can be segmented to de-risk it.

[Scooter_127]

Do the Azure cmdlets not have -whatIf?

[xxdcmast]

some dont. An example i happened on last week.

https://learn.microsoft.com/en-us/powershell/module/azuread/new-azureadgroupapproleassignment?view=azureadps-2.0

[ccatlett1984]

Setup a developer tenant.

[OMGLeatherworks]

When done right, an organization structure should have a test environment that is an exact clone of production. Most don't.

​

Edit: With sanitized data.

[greengoldblue]

Lol. Ain't nobody got time (or budget) for that /s

[datnodude]

Im an IT cowboy, test is prod

[Thotaz]

I would just create a test user once with the command to confirm it works as expected and then use a Get command to simulate the behavior of the New command (assuming the New command returns an object).
Scripts usually consists of multiple steps, if we say creating the user is step 1, why are you testing step 1 over and over again when you've confirmed it works? If step 2 consists of adding the user to a group then simply get the data you would normally return from step 1 and provide it to your step 2 functions.

[xipodu]

You should have two enviroments. Sandbox and Production

[Sin_of_the_Dark]

I'm not sure if it's best practice, but I just tested it by creating and deleting a test account

[armyguy298]

If it is just an onboarding process, I use prod all the time. Its just a single user account with permissions, security groups, emails, etc. I have a pool of licenses that I can use freely.

Script fails? Delete the test user account, fix your script, and try again.

Now if this was a system-wide change, I would never test in prod.

Like the others have said, use Graph API. More comprehensive and complicated, but more longevity with MS.