Restore a Deleted Office 365 Group with PowerShell

Oops…So I accidentally deleted a few O365 groups last week.  Happens to everyone at some point right?  Luckily, as long as it has been less that 30 days since you deleted it, you are in the clear and can restore it!  Note: If you were a try hard and used Remove-MsolGroup to delete the group, you’re screwed.  Full disclosure the very detailed walk through I followed can be found here, but I am going to do my own quick write up for future reference.  With all that being said, strap in!

We need to start by installing the AzureADPreview PowerShell module.  Yeah, it’s in preview (haha).  So pop open a PowerShell window as administrator and run the following.  If you have a previous version of the module you will need to uninstall it and install the most up to date version.

Tough stuff.  You may receive the following prompts to download the repository and that it is untrusted.  Accept them, they’re not super hackers or anything.

Now we are all prepped and ready to go.  If you closed that PowerShell window get it open again as administrator.  Run the following to restore your group (further instructions below).

It’ll take a few seconds but you will now have your group restored and can go back to normal.

 

Convert Federated Domain to Standard with PowerShell

This is a rather unique scenario that I found myself in recently.  I must admit, tearing down domain federation is infinitely easier than getting it set up!  Anywho, the following details the steps involved in converting a federated Office 365 domain to a managed domain and removing DirSync from Office 365.

1.) Open a PowerShell window as Administrator on a box with the msol cmdlets and connect to your Office 365 tenant

2.) Run the following command to convert the domain to a standard domain

3.) Run the following command to remove DirSync from Office 365

 

Monitor Membership of Domain Groups with PowerShell

Let me start this one off by saying this is not an optimal solution, but in a pinch it gets the job done.  Also, I kind of rushed this so there is a lot of code and it could definitely be shortened up if so desired.

Now that that is out of the way, the following script monitors groups that you wish monitor on a white list basis.  This means it requires a lot of upkeep if you are in a rapidly changing environment, but luckily I am not.  It is quite simple to add groups should you need to so that’s a plus.  In the event of someone being added to one of the groups that isn’t on the corresponding white list, you will get an email notification.  I just deploy the script as a scheduled task that runs every hour.  Simple but effective.

 

 

Disable/Delete Computer Accounts Where LastLogon Older Than 6 Months/1 Year

Been doing some AD clean up lately and I wanted to automate the process for stagnant computer accounts.  To do so I wrote two PowerShell scripts that I run once a month as a scheduled task.  As you’ll see below, I did need to exclude a few machines that have a certain naming standard.

Disable Computer Account with LastLogon Older Than 6 Months:

Delete Computer Account with LastLogon Older Than 1 Year:

 

List Group Members Whose User Accounts are in a Specific OU

Wanted to pull a list of users who were a part of a certain group last week, but I only wanted the group members that were located in a particular OU in AD.  I accomplished this with the following script:

 

Monitor DHCP Scope Available Addresses with PowerShell

Had an influx of folks come into the office last week and one of our DHCP Scopes actually almost ran out of available addresses (which I found out after the fact by chance).  This inspired me to make a quick PowerShell script deployed as a scheduled task to notify me when a scope is low on available addresses, as seen below:

 

Azure AD Identity Synchronization Error 105: UserPrincipalName is not valid

Had a request to change the UPN from one Federated Domain to another today and it gave me a bit of trouble.  I made all the appropriate changes in AD thinking it would be that simple, but alas I began getting the following error on my DirSync to O365:

Unable to update this object in Azure Active Directory, because the attribute [FederatedUser.UserPrincipalName], is not valid. Update the value in your local directory services.

Looking at the synchronization service I got the same error with the error number of 105 (I was really hoping for more information).  I did some digging on the internet and came across this article that contained the answer to my problem.

Turns out that when switching a local AD account from one federated domain to another, Azure AD/O365 doesn’t like that too much and doesn’t make the change for you.  Lame.  So I used the following bit of PowerShell to resolve that:

Then kick off a Full Sync on your DirSync box, let it finish, and you’re good to go.

 

Controlling Windows 10 “Bloatware” Apps

It is no secret that Windows 10 has a nasty habit of installing software that we do not want installed in our environments, and this seems to be something that Microsoft has no intention of changing in the near future.  The only “easy” solution is to get your hands on Enterprise LTSB, but then you do not get feature updates.  Anywho, presented with this issue and the fact that my customers only pay for Windows 10 Pro (shocker) I came up with a PowerShell script to only keep the apps that I dictate installed, with a little help from the Obi-Wan you all hear about so frequently.

A quick run-down for those who are not yet familiar with Windows 10 there are two types of packages that we are concerned with today; AppxPackages and AppxProvisionedPackages.  AppxPackages are the packages of the currently installed Microsoft apps for a particular Windows User Profile on the machine.  AppxProvisionedPackages are the pesky devils that install the apps upon new user profile creation on the machine.  Naturally, the latter are the ones we are most concerned with, but we want to ditch any of the AppxPackages that may linger on.

Also, I have included a quick check to make sure the PowerShell script will only run on Windows 10 1703 or lower.  This way I have time to test on the next version and make sure this script doesn’t screw anything up before I allow it to run on client machines.

When it comes to deployment I push with GPO and run the script at computer startup, but I run a batch script that copies the .ps1 file down to a restricted folder on the local machine first.  I do this because this script needs to run as system to be fully effective.  I also add the following arguments when running the script to hide the PowerShell window while it’s running.

Office 365 “Mailbox hasn’t been migrated to Exchange Online” Error

When working with an on-prem AD synced with O365 via Azure AD Connect (DirSync), I have been coming across this error from time to time with accounts that used to be connected with an on-prem Exchange server.

Error message received in Office 365:

To resolve this issue, follow the steps below.  As a general disclaimer, this will remove any existing mailbox.

  • Remove the AD account from the DirSync group and any groups that may apply licenses (essentially anything to do with O365).
  • Run either a Delta or Full sync via Azure AD Connect

  • Open PowerShell as administrator and run the following command:

  • Clear all of the AD User attributes beginning with msExch
  • Re-add the user account to all appropriate groups and run another Delta/Full Sync
  • Apply license in O365 and confirm mailbox creates successfully

Export sAMAccountName’s from AD OU

This is most easily accomplished (at least I’ve found) using PowerShell.  The following will do the trick: