AzureAD

Module Monday July 31, 2023

July 31, 2023 by ClaytonT Leave a Comment

Well, here it is! Module Monday, but this one is a module I’ve been working on for a bit and figured it’s time to put it out to the community for others to enjoy and improve. Have you had to test PowerShell scripts on your 365 tenant and really didn’t want to use your production environment, but wanted to keep the close as possible for testing accuracy? Then you’ll want 365AutomatedLab in your tool chest. It can also be used to add multiple users to an environment from an excel sheet or add multiple groups to a user per their title from an excel sheet. Hope you check it out and leave some feedback! So much I want to do with it and super excited about this project that I feel can help so many!

I’ll be doing some blog posts and video tutorials in the near future. Any preferences?

Thanks to Andrew Pla for the extra push 😆

https://github.com/DevClate/365AutomatedLab

Read-Only Friday 365 Developer Program

July 14, 2023 by ClaytonT Leave a Comment

Want to have some fun with Office 365, but don’t want to mess up your production environment? Or what about being able to try out scripts and not having to brace yourself as you run them and hope they don’t clear out all your data? Now you can do whatever you want with the Microsoft 365 Dev Center.

That is right, up to 25 E5 licensed users at your disposal for 90 days and will be renewed as long as you are using it. They will even create 16 users for you, mail traffic, and more. This isn’t just for PowerShell, this all aspects of 365.

Awesome, right? Here are few examples:

You could copy up to 25 of your current users and import them into this Developer tenant and test scripts see exactly how it would work with your information. Think of those times where you test a script with fictional users and your script works perfect, but once you put it into production, your script fails because one username had a character that your test data didn’t have. Now your spending unnecessary time trying to figure out what went wrong when it worked perfectly in proof of concept.
You want to test new features or policies, but you don’t want to enable them in your production environment, as your not 100% sure how it will react to your environment. Configure this test environment how your current tenant is then enable those features or policies you want to test. Much safer to test in the dev environment, then do it in production and all of a sudden your users can’t access critical resources or anything at all!
Your boss wants you do a proof of concept on how to streamline the onboarding process and to make it as simple as possible for the organization. It is recommended that you use Sharepoint and Teams as the company already uses both and are familiar. Instead of using your production environment, you can do this all in the dev tenant without affecting anything in production. You can even invite key players in this project to login and test it with you. Now you don’t have to worry about a teams alert that you setup for when a new hire has been added to AD or Microsoft Entra ID spamming a your production channel because your script or flow errored.

These are just a few scenarios that the 365 Dev tenant can be useful, but there are so many more. I’m barely scratching the surface, and hope you sign up right away for this if you haven’t already. It is free, if you administer or develop 365, you need this.

I hope you found this helpful, and if you have any questions, I’d be glad to help out in anyway I can.

One-Liner Wednesday March 15, 2023

March 15, 2023 by ClaytonT Leave a Comment

Today’s one-liner may not be a direct PowerShell command, but it can be run inside the PowerShell terminal. Are you using Intune, or looking into using Intune? If your already using it, you know by default when you add a user it sets them as a local administrator(I’m not sure exactly why, but that can be a topic for another blog post), and of course we don’t want our users to be local administrators on their computers. To resolve this issue, all you need to do is remove them from the local administrators group like below.

net localgroup administrators azuread\user@domain.com /delete

The only change needed is changing “User@domain.com” to their login address. I’d recommend adding this to your new device script, and if you do not have a new device script, I’d start one now, so you can keep adding and automating things to save you time and have consistent deployments.

Also, take a look at Azure Functions to see how you can deploy code and automate things on a bigger scale.