PowerShell

Azure AD: update CompanyName

Bix

In our Azure tenant, we have established naming conventions for O365 Groups, because we have a lot of users from different organizations federated in one single tenant, and we want to be able to sort out groups or it becomes total madness.

We have chosen the property CompanyName for this naming convention. From now on let’s call these organizations “companies”, it’ll be easier.

We have the usual 2 kind of users in our tenant: On one hand, the synchronized user from every company’s AD (recognizable with their UPN being firstname.name@thecompany.ext , and on the other hand, classical Cloud Identities directly created online (UPN is firstname.name@tenantname.onmicrosoft.com)

We have an AAD Connector which sync’s to Azure, users’ info from the source AD of every company, and within the numerous Connector Rules, we write for each company, the correct CompanyName (yes, it is hardcoded for each but we have about 20 companies so that is manageable).

But recently, in the context of PowerBI Pro, where in order to create App Workspaces you actually need to create an O365 Group, I have to give the Group Creator to Cloud ID’s who, not being part of any Company, had the CompanyName property to null, and thus couldn’t respect the naming convention, which blocked the group creation.

I just needed a way to update the CompanyName manually, and that’s another story.

I’ve tried the following:

  • Set-AzureADUser: you can update almost any property with this, BUT the CompanyName.
  • Set-MsolUser: plenty of other parameters to update, but still no CompanyName.
  • Found fancy solutions stating the Set-User cmdlet from Exchange (with the -Company argument) would somehow impact the CompanyName in Azure, but it didn’t appear to be true (at least for unsync’d Cloud IDs)

So, ticket to Microsoft, and some nice Tech Support guy first confirmed the attribute was read-only once in Azure and only writable through the Connector Rules, and I felt desperate because I didn’t feel like configuring Connector Rules for unsync’d objects.

Then a second miracle mail came, and Tech Support told me that very recently (February 2019), Microsoft Graph underwent some changes and that the CompanyName is now writable. Not wanting to dive into Graph, this led him to finally find the cmdlet to update the CompanyName!

TL;DR: Here is the command:

Works like a charm!

Just a little advise: you need WMF5+ for easy usage of the AzureAD module.

Sources:

PowerShell one-liners: get DNS info

Bix

As you all Microsoft-sysadmins now know, PowerShell is t3H sh1T everybody is supposed to use, more and more.

Windows guys now have the ever-wanted ability to pipe stuff, we can execute commands in one line (also called “one-liners”), how wonderful  (you hear the sarcastic tone, I hope..).

Sometimes these commands are very easy, sometimes they’re a bit trickier, anyway I will record here some of the cool ones I met.

Last example in mind: a colleague asks me to provide him “a list in an usable text file, of the DNS info (static/dynamic record, record type) regarding Linux machines in our domain”.

We have a pretty complex naming convention here. All servers have a prefix of three letters followed by an hyphen, and then some random word to describe the server functionnality. Linux machines have prefixes all beginning with “L”  (how strange).  Problem is, laptops also begin with “L” (prefix “LP-“). Oh and we also have a few Linux servers with some specific random name as prefix (let’s call it “randomname” here).

Here’s the one-liner:

I love regexp’s as much as I suck at them, that’s why I’m so proud when I manage to get one to work for what I want! (one is happy with what one can..). So yeah in our example here, “randomname_2” is also taken into account.

This outputs a nice text file looking like the following:Powershell oneliner - DNS - output

where Timestamp=0 means static record, and the other fields are self-explanatory.

This must be executed on a server with the DNS Powershell cmdlets (easiest way : a DNS server..) and PowerShell version 4 or later (might work with v3, haven’t tested, but certainly doesn’t work with v2).