Azure AD: update CompanyName

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:

SharePoint: move a document library with Export-SPWeb

For some laziness reasons, and mainly because I had so many issues (or fear of issues, you know how that is) with the PowerShell commands to manage site collections, I got used to stsadm command line, which is something from SharePoint 2007 a.k.a. MOSS.

It still works with SharePoint 2010, and also in SharePoint 2013 with some workaround. But clearly, the SharePoint Management Shell is the way to go now, and I have been advocating Powershell for long enough, to go and try to make the effort to use it here.

I got a request from a user, to move a document library with versioning enabled, from a site collection root to a subsite, while keeping the whole version history of all documents within.

Opening the document libraries (source & target) with Explorer and copy-pasting works and even keeps version history, but only within the same site collection. Moving documents this way to a subsite, removes the whole shebang.   So yeah, it seems like we’ll have to use the dreaded Export-SPWeb command.

“Dreaded”, because the official documentation about it is poor, lowly documented and examples are just not complete, and you WILL get errors hardly understandable.
Blogger Blksthl provides a more documented version, but it still lacks to explain about this thing we use at work: managed paths. Even if in the URL nothing makes the difference, Managed Paths are not the same as site collections; they are a “sub-division of a web application”, and clearly they behave differently.

Logging on the App server with Farm Account (not sure such an elevation is needed, but I want to avoid permissions issues).  The aim is to migrate the document library MyDocLib from the site collection http://webapp.mysite.be/managedpath1/MySiteColl, to the sub-site http://webapp.mysite.be/managedpath1/MySiteColl/MySubSite/, keeping all versions of all documents – and user security, of course.

Now let’s try various versions of the syntax, since it’s never indicated where to put the managed path:

Oh yeah, even the value for parameter -Includeversions is not even well documented in the official doc. They mention 4 possible values but not exactly what to enter for each of them. I had to get more info on this on another TechNet article

The error message changes a bit, and it’s funny that it mentions the usage of stsadm.exe in the PowerShell command itself…

After some research, it might appear that the -itemurl parameter might require a full path, let’s try:

For some reason I didn’t include MydocLib in that command, and I don’t know if the result would be the same if I had. Anyway, you’ll find a lot of literature about this <nativehr>0x80070057</nativehr> error, but nothing I could get much from.

Ok enough playing, here is the way to success.

The problem is to know exactly what to put in –identity and -itemurl. For the first one, it looks like the full site collection path where the doc lib is located, is correct. For the second one, it’s another story, and thanks to TechNet user HAZET in yet another post on the problem, here is the SharePoint shell command to know about your site collection elements’ itemURLs:

The result will be something like:

Okayyyyy so the Managed Path has to be indicated in the -itemURL. So here’s the final -and working- command:

-identity: full site collection path
-itemurl: document library path with managed path and a starting slash.

Now you have your .cmp file ready to be imported in the target sub-site. The Import-SpWeb command doesn’t need an -itemurl parameter so you might think your problems are over .. but not quite yet:

The prompt is the correct directory, the file with this precise name exists.  OK this is PowerShell so maybe  .\MyDocLib.cmp ?  Nah, same error message.

In fact… Export-SPWeb can work in the current directoty, but Import-SPWeb cannot (if anyone finds any logic in this, let me know). You need to specify the full path:

It works!

PowerShell one-liners: get DNS info

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).

Remote desktop error on Windows 2012

You want to connect with remote desktop to a fresh Windows 2012 server  (any edition) and you get the “Remote Desktop can’t connect to the remote computer for one of these reasons” generic message that isn’t giving anything except maybe a headache and the will to punch your screen:

Remote2012_00
For once, the Microsoft-style error message doesn’t totally lack of sense, especially about the last point: “is not available on the network”.

I don’t actually remember how it is with a Server 2008 out of the box, but I don’t remember having had those issues – then again, the guys at work making the templates for our virtual machines in 2008 had perhaps already fixed this…

Anyway, we’re talking here about Windows 2012 (“R1” or R2).

First things first, ensure the remote desktop is enabled.  Connect to your machine with the console (VMware/Hyper-V/whatever, or physically to the server if it is … a physical server)

Ensure the following is checked: Control Panel > System and Security > System > Advanced system settings > Remote > Allow remote connections to this computerRemote2012_01
This is greyed out here because we activate this through GPO.
Also, note that the checkbox below is NOT checked; this is to allow us to use software such as mRemoteNG (that I strongly advise). In a closed and secure environment, this is OK not to check.

So, Remote connections are allowed but you still get the error message, so there is a firewall issue as you may guess.

Of course you can totally turn the firewall off, but if you’re like me a bit, you don’t like opening all the doors of your home just because someone in your household hasn’t got the key to open one.

So let’s use cool powershell/prompt commands to solve this:

will output the three rules and their current Enabled status. You should see it to “False”

will open what needs to be opened.

will double check that everything is OK.

The global output should look like this:

Remote2012_02

Enjoy your remote connection!

Sources & additional info:

 

What is locking my file or folder?

We’ve all had this.  You want to delete or rename some file or folder, and you get the very dreaded following window:
filelock-cannotdelete

You probably already know about the locked files and checked the Server Manager > Roles > File Services > Share and Storage Management > OpenFiles   (this is the path for Win 2K8).  Your folder is not to be seen, and it gets you mad, I know.

Then you Google some, and you find some miraculous third-party software which-will-solve-all-your-problem-but-please-click-next-next-next-and-don’t-read.

filelock-unlocker
Delta Toolbar?  SRSLY?

Then let’s think: it’s Windows, we are in 2015; what about Powershell?

Beam Us Up Scotty proposes a command for this, let’s try it on that example directory:

It might be actually good for files, but in the case of a directory, it returns nothing 🙁

Out of the box, I haven’t found a way to get what I want:  clearly identify what the hell is locking my file or folder.

There is a Sysinternals executable called Handle.exe (which I would love to decompile some day and inject its commands into some PS!) which looks promising.

Note that you can run this executable from a remote location, but not from a certain location, aimed toward a remote machine where the file is locked.

The Lonely Administrator and Stackoverflow propose solutions using this, let’s try:

  1. Download Handle.exe from the official Sysinternals site. It’s a safe lonely executable, no crappy toolbar, no adware and the like.
  2. Put it on some network share.
  3. Write a nice PS function to use Handle.exe. As we won’t reinvent the wheel; just grab the one from the Lonely Administrator (the second “Click to Expand Code”)… it’s well done and works fine (*).
  4. Put the function in a file (let’s call it Get-LockingProcess.ps1) on a share (e.g. the same as Handle.exe, let’s call it MYSHARE for the example).  Be sure to edit the path to the Handle.exe file (variable $Handle in that code) to match your network share.
  5. From anywhere where a file or folder is locked, as long as you have access to the said share, you open a Powershell window, you include the Get-LockingProcess.ps1 (using the dot command for instance) and then you call the function with the locked directory.

Let’s try this with our example dir.  I put Handle.exe and the Get-LockingProcess.ps1 files on \\MYSHARE:

Pretty clear: you have the directory opened in a cmd window!

This is from a system admin’s point of view and wanting to give any power user a quick and easy way to identify locked files/folders.
Of course you can also do this locally, and/or only output Handle.exe to a file and Ctrl+F into that file, but it isn’t as fancy ! 🙂

 

(*) For future’s sake, here is a copy, with cited source:

Doesn’t that regex totally PWNS? 🙂