Key things are:

• The URL to call (via POST) is https://api.fabric.microsoft.com/v1/workspaces/@{variables('WorkspaceID')}/items/@{variables('PipelineID')}/jobs/instances?jobType=Pipeline
  • No need for a body, unless the pipeline needs one.
  • Here’s the documentation for the URL being called (there isn’t much!).
    • The example there shows a payload, ignore that example. I realized later that the payload is just an example of parameters being sent to a pipeline.
• Use the HTTP with Entra ID preauhorized connector. When setting up authentication, use the following:
  • Base URL is https://api.fabric.microsoft.com/
  • Resource URI is https://analysis.windows.net/powerbi/api
• Be sure to give whatever account you sign in with here rights to the workspace. In my case it was a service account I use and I gave it Contributor rights.

That’s more or less it!

Irritatingly, I kept getting an Unauthorized error when testing this.

But I wasn’t actually unauthorized, coz the body had a different error:

If you are actually unauthorized, the error is different.

Thanks to Gemini, I realized what was going on. Since the pipeline doesn’t run straight away, what happens behind the scenes when you do an HTTP request is that you are getting a Location URL in the reply header. You are supposed to keep querying that to get updates on what’s happening. But… when the HTTP connector does that, for some reason it doesn’t connect using the signed in account, and that’s why we get an unauthorized error.

To fix it, first turn OFF asynchronous pattern. Click the 3 dots of the connector, go to Settings:

With this turned off, the connector won’t follow the Location URL. Instead, we got to do that.

So immediately after the HTTP connector, add some code to get the Location URL from the header.

Here’s what I put in the input of the StatusURL compose object: outputs('HTTP_Request')?['headers']?['location'] (Replace “HTTP_Request” with whatever is your case of course)

Now, if I were to query that URL using the authorized connector, I will get a response. That response looks like this:

{
  "id": "d9c77016-8e5d-4eed-a0df-59266367cf8d",
  "itemId": "3bfc37e7-8837-430d-8af4-6c6397da24d5",
  "jobType": "Pipeline",
  "invokeType": "Manual",
  "status": "NotStarted",
  "failureReason": null,
  "rootActivityId": "7f526ae4-bdb6-4fa8-b51e-2a626b3c9d62",
  "startTimeUtc": "2026-03-27T14:47:00.8",
  "endTimeUtc": null
}

Key thing is the status field. Looks like that has the following values:

• NotStarted
• InProgress
• Completed
• Failed

I couldn’t find any documentation on this (and Gemini gave wrong results such as “Succeeded” instead of “Completed”).

So what one must do is setup a loop that calls this Location URL (authenticated request, GET) checks the value of the status field, and keeps looping until it is either Completed or Failed.

Like so:

Here’s the formula:

or(
    equals(body('HTTP_Request2')?['status'], 'Completed'),
    equals(body('HTTP_Request2')?['status'], 'Failed')
)

And then one can send an HTTP response to the caller of the Logic App/ Power Automate.

Here’s the condition block:

Note that I set the condition to also run if the do/ until loop timesout. This way it returns and error if the loop doesn’t finish for whatever reason.

That’s all! As the author of the blog post I linked to at the beginning of the post, I look forward to the day this is an in-built connector.

What you have to do to fix this is go to the Admin Portal in Engage itself, and add the user as a Verified admin (the other two roles don’t suffice). Then they can create new communities.

Hope the next time you ask GenAI this question it sees this blog post and answers correctly for you.

ps. If you added the Verified admin role you won’t be able to remove the user as it is grayed out.

You unassign the user from the Yammer Administrator role in this case to remove them from Verified admin. This isn’t an issue for the other two roles as you can modify it from the Engage admin portal itself.

Started to use Zed again earlier this week, and one one of my machines it showsa warning that the environment variables failed to load.

Clicking on it opens up the logs, which has a bunch of entries like these:

Caused by:
    login shell exited with exit status: 1. stdout: "\u{1b}(B\u{1b}[m", stderr: "bash: cannot set terminal process group (-1): Inappropriate ioctl for device\nbash: no job control in this shell\nopen terminal failed: not a terminal\n"
2025-12-13T10:09:19+00:00 ERROR [project::git_store] failed to get working directory environment for repository "/Users/rakhesh/xxx"
2025-12-13T10:09:19+00:00 ERROR [crates/project/src/environment.rs:227] capturing shell environment with "/opt/homebrew/bin/bash"

(It seems to be for each of the folders that are git submodules).

Trying to get to the bottom of this reminded me that I had encountered a similar issue with VS Code in the past. What happens is that on the problem machine, I have set it to launch tmux whenever a new login shell is spawned. And that was causing an issue with Zed.

In VS Code the VSCODE_RESOLVING_ENVIRONMENT variable is set to 1 when VS Code is resolving the environment variables, so I was using that to not launch tmux in such cases. Something along the lines of:

# Only if $VSCODE_RESOLVING_ENVIRONMENT is empty, launch tmux
if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]]); then
    # launch tmux
fi

There doesn’t seem to be the equivalent of that for Zed, though someone’s asked for it recently.

I added the following line to the top of my .bash_profile file.

env > ~/Downloads/blah.txt

This showed me that a variable called ZED_TERM is set to true. So I thought I’d use that in the same place I check for VSCODE_RESOLVING_ENVIRONMENT but it didn’t work.

# Only if $VSCODE_RESOLVING_ENVIRONMENT and $ZED_TERM are empty, launch tmux
if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]] && [[ -z "$ZED_TERM" ]]); then
    # launch tmux
fi

Adding the same env line at this point of the code, before launching tmux, showed me that ZED_TERM isn’t available anymore. Weird.

Not a problem, I added this at the very top of .bash_profile where ZED_TERM was visible.

# Create a variable of my own
if [[ "$ZED_TERM" == true ]]; then ; 
    ZED_RESOLVING_ENV="1"
fi

Then I can do:

# Only if $VSCODE_RESOLVING_ENVIRONMENT and $ZED_RESOLVING_ENV are empty, launch tmux
if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]] && [[ -z "$ZED_RESOLVING_ENV" ]]); then
    # launch tmux
fi

And problem solved! No more errors in Zed as tmux isn’t launched when it tries to resolve the environment variables.

ps. For those who know and loved the Atom editor, Zed is Atom reborn (well, more like rewritten to be super fast and very minimal).

Reading the docs for this connector, there is a section on how to authorize it. You have to download a script from GitHub and run it as Global Admin.

What the script essentially does is search for the Power Platform App Id mentioned above (d2ebd3a9-1ada-4480-8b2d-eac162716601) and if it does not exist, create it. Then it gives a list of first party apps (Graph, SharePoint Online, etc.) and asks you to choose the one you want to allow access to. After that, you can choose the scopes you are interested in granting access to. It’s pretty neat, and nice of Microsoft to provide such a script.

If you want to avoid all this though, there’s a variant of the above connector that is preauthorized.

Fill that as as below, and it works.

From the documentation, it sounds like this one too is limited to a number of applications and scopes; and anything extra will require use of the non pre-authorized connector and script.

Easy. Use Plus Addressing. What plus addressing means is that every mailbox enabled user also has a “+<whatver>” suffix they can use as an email address. That is to say, if my email address is abc@mydomain.com, if plus addressing is enabled I can receive emails at abc+123@mydomain.com, abc+xxx@mydomain.com, abc+laksdasd@mydomain.com, and so on…

Nothing new about this concept, and this is something one commonly uses in Gmail etc. when handing out email addresses to a website. Use a plus address so you know which website is then spamming you, plus you can create rules to put them into separate folders etc.

To use this in admin accounts in Entra, assuming it is setup in the organization, all we need do is add a plus address to the admin account.

Now any service sending an email to the admin account by looking up its mail attribute will use the plus address you put in there, and Exchange Online will route that email to your regular account.

Things get a bit tricky when it comes to external emails, including notifications from Azure and Entra ID. If you have something like Mimecast which is the mail processor for external emails, you need to enable plus addressing there too. Mimecast calls it Sieve Sub Address policy (named after the RFC). Instructions are in their documentation, and here’s what I did.

First off, if you use Mimecast AAA then the steps below must be done there, not on the Federated instance.

It is possible to enable plus addressing on the Mimecast side for everyone, but we opted to do it for a few users. Mainly our admin accounts. So we created an address group to hold these addresses.

Go to Users & Groups > Policy Groups > Create a new group.

In that add the addresses. The document is a bit confusing, but through some trial and error what we discovered is that you must address both the plus address(es) you want to allow, and also the user’s default address. So, for example, if I want to allow abc+def@mydomain.com I must add both abc+def@mydomain.com and abc@mydomain.com here. Add any number of plus addresses, but they won’t work unless the base address too is present.

Then go to Policies > Gateway Policies > Select Sieve Sub Address.

Create a new policy here. Give it a name, and in the “Emails To” section select the group we previously created. Below is a screenshot from our setup:

Mimecast is neat in that it supports two types of plus addresses, and for each of these it can also strip out the plus address bit and send to the backend system in case that system doesn’t know of plus addresses. So if Exchange Online didn’t support it, we could have still used it for external emails thanks to Mimecast.

We went with “Enable + Delimiter Recognition” which enables plus addressing of the sort I showed above, and doesn’t strip the plus address bit.

Save it, and that’s all really! Now plus addressing works for external emails too. We tested this by sending emails to the admin accounts internally and externally by typing out the full plus address rakhesh+admin@thesyndicate.com, as well as assigning the admin account an Entra role to get Entra ID to generate an email. This came though, confirming that Entra uses the mail attribute we added to the admin account, and the email flows through Mimecast and is delivered.

The movie also ties with a lot of the books and podcasts I consume nowadays. It’s very in with the times. All about the gig economy and working conditions and life being hard and pointless. You got to be a certain kind of mind to see and hear all what’s happening around you and then make a movie out of it that conveys the message but isn’t preachy or doom and gloom. And Aziz Ansari definitely has that sort of a creative mind! And that goes for most writers and directors of course – I am always impressed at how the good ones have a vision and can “show us” the world through their eyes.

A TV show I watched recently was “The Bombing of Pan Am 103”. Again, very impressive and touching. The creators managed to convey all the emotions associated with the incident – the kindness of the townspeople of Lockerbie, the investigation efforts across US and UK, the frustrations experienced by the relatives of the victims – so many things! I had no idea of this incident until I saw the TV show but it had me hooked and I really felt like I was there. Again, that’s an amazing thing to be able to do as a creator.

Another brilliant TV show we saw recently is “All Her Fault”. The show wasn’t at all what I was expecting it to be. It touched upon a lot of themes, but was never preachy or focusing too much on any one issue. Nor did it feel all over the place. Instead it did an amazing tightrope across everything and I loved it! A child is kidnapped by his nanny, and from there the show touches upon a lot of current issues – rich people, the struggles of working couples, childrearing, domestic abuse (of a different sort), and so on. I won’t go into the details but I definitely recommend the show. Looks like the creator and directors are all women too, and that really shows in the way the show treats its matter. (So is the author of the book the show is based on actually. I haven’t read the book).

That seemed a bit inconvenient, and I was curious why it wasn’t finding the fingerprint – especially coz my phone had fingerprint and face unlock setup.

I figured out what to do. One must add fingerprints to the work profile too. Like so:

Open the Settings app
Type “fingerprint” and select the one for Work
If “Fingerprint for work” already has an entry, you don’t need to do anything. If not, click on it. Follow the instructions to add a fingerprint. You may also be prompted to register your face – go ahead and do that too.
After adding a fingerprint (and optionally, face) it looks like this.

Now when I open the app (I had to reinstall it, but I think there’s a setting in the app if you have already signed in with the password option – click on the hamburger menu on the top left in the app, go to Settings, and toggle Fingerprint) I get prompted as before but can select the fingerprint option.

Click “YES PLEASE” and I get prompted to confirm the fingerprint.

Yay!

iOS is easy. Push the app out to a group. Also push out an app configuration so the app knows what to do when a user clicks on it. Easy peasy.

This article has a list of the keys you need to push out.

And you can do so via an XML file like so:

<dict>
     <key>SFSF_Instance</key><string>XXXXX</string>
     <key>SFSF_DomainName</key><string>BLAH.successfactors.TLD</string>
     <key>SuccessFactors</key><string>GUID</string>
</dict>

Android should be similarly easy. Push the app out to a group. Create an app configuration and assign to the group. With Android you get a configuration designer with prefilled questions when you choose SuccessFactors as the app.

However, this didn’t work. The app would launch and then throw an error:

No apps found: There are no apps on this device that your organization allows to open this content. Contact your IT administrator for help.

Weird. I thought maybe the app expects Chrome or something, and since our Android work profile didn’t have Chrome it was complaining about that. But adding Chrome didn’t make a difference.

Contacting customer support was unhelpful as they kept saying we must add their app to the App Protection policies. Which makes zero sense, coz SuccessFactors isn’t available as an app to select with App Protection policies.

The fix in the end was to exempt SAP SuccessFactors from the “Send org data to other apps” setting of our default App Protection policy. Thanks to this blog post that gave me the idea. In our case the “Send org data to other apps” setting was set to “Policy managed apps” so I think what’s happening is that when the  SuccessFactors app launches it opens up Edge to do the SSO (it knows what to do coz we are pushing the app configuration) and then Edge is unable to send back to SuccessFactors as it’s not a policy managed app. That’s why the SuccessFactors team were saying we should add SAF SuccessFactors to the App Protection policy, but that’s wrong advise coz the app isn’t available to be added. Instead, we must exclude SAP SuccessFactors from the list of apps that are exempted from the “Send org data to other apps” restriction.

I found the id by looking at the app in Intune. It’s com.successfactors.successfactors in case anyone wants to copy-paste.

In a similar vein to my tinkering with Hue lights… I have a BenQ ScreenBar Halo on my monitor which I’d like to turn off when I logoff or my Mac goes to sleep. The latest version of the Halo has some sensors that can detect when you are around, but I don’t have that nor have any plans of buying that, so I wondered what else I can do.

I had a Meross SmartPlug lying around, and I figured maybe I could plug the ScreenBar into the Meross. And then use some API commands to turn off the on the SmartPlug maybe? Turning off the SmartPlug will turn off the lights, and turning on the SmartPlug won’t turn on the lights but I can manually turn that on – no big deal. (Update: Turns out the ScreenBar automatically lights up if it was previously lit when power was turned off. So turning on power to the SmartPlug effectively turns on the ScreenBar too).

I tried to find some way of dealing with the Meross API, and also found this Python library. I didn’t want to use that, but looking at the library I realized I could install a proxy app on my phone (e.g. proxypin or proxyman) to see what commands are being sent to the SmartPlug when I turn it on and off. That was pretty straight forward, and I found two HTTP calls too to turn off and on the plug. The HTTP calls worked too, just that they weren’t super reliable. They seemed to work as long as I put a minute or two between them – so I can turn on the plug, but if I send the command to turn off immediately, it doesn’t work. Wait 2 mins and send the command, and that works. Ditto for turning off.

That wasn’t super ideal, and I was wondering what else I can do when the idea struck me of using Shortcuts. The plug in question supports HomeKit so I have it setup in the Home app too; so I could easily create a shortcut to turn on the plug, and another shortcut to turn off the plug. And since I was using Hammerspoon to detect when I log off and login, it would be great if I can use Hammerspoon to run the appropriate shortcut.

Turns out that part is dead easy! All I need do is:

hs.shortcuts.run("<name of the shortcut>")

So I created a second watcher along the lines of my previous one:

function toggleSocket(eventType)
  if (eventType == hs.caffeinate.watcher.screensDidUnlock or 
      eventType == hs.caffeinate.watcher.systemDidWake) then
    hs.shortcuts.run("Desk Socket ON")

  elseif (eventType == hs.caffeinate.watcher.screensDidLock or 
          eventType == hs.caffeinate.watcher.systemWillSleep or 
          eventType == hs.caffeinate.watcher.systemWillPowerOff or 
          eventType == hs.caffeinate.watcher.screensDidSleep) then
    hs.shortcuts.run("Desk Socket OFF")
  
  end
end

socketWatcher = hs.caffeinate.watcher.new(toggleSocket)
socketWatcher:start()

And that’s it, really! Job done.

Hammerspoon is sooooo awesome!

I always thought a luddite was someone who hated technology, or who couldn’t understand new technology and refused to change with the times. That’s how I always used the term. But while reading this book I realized how wrong I was. Luddites weren’t against technology, they just were against technology that made it worse for humans. The same way one could feel about AI or any other technology – I am not against AI, for instance, when Copilot summarizes a Teams meeting so I don’t have to watch the whole thing but can quickly understand what happened – but I am against AI when it is presented as something that can replace humans or the work they do (write code, design images, write legal opinions, replace customer support). And back then and now, the issue was one of policy and greed – what the Luddites were against was how the factory owners were using these machines to get rich by stealing the work/ profits of the workers. The workers took pride in their work and were happy to work for a fair price, it was only when factory owners wanted to replace the workers with machines because that way they could sell things for cheap and eliminate dealing with workers, that they started smashing machines! It’s so crazy how so much of that resonates with what’s happening in the world today.

Worse, machines had the quality worse in a lot of cases, but that was fine coz the price is what mattered.

On the policy front it was the wars England was fighting with France that brought down the market (less demand for the goods), giving factory owners all the more reason to push for machines as they can lower costs and not deal with workers. So many themes that rhyme between then and now!

And all this is from just the first 100 pages or so. Madness. I never ever thought about the Industrial Revolution this way. You visit a museum and all everyone ever talks about is how the Industrial Revolution paved the way for progress and made our lives better etc.; which, no doubt, it did, but there was a huge price to pay for it and that was only paid by the workers.

I knew from English studies at school where we had to read Charles Dickens on how children worked in these factories and things were tough. But again, that was just a “story”. In this book though, there’s a lot more on how such children were mistreated, and why children were used in the first place. Factory owners didn’t need workers to run the machines, children were ideal coz they didn’t cost most, were more pliable, and you don’t really need much skills to operate the machines (as opposed to the cotton weavers and others). And just like you hear of inhuman working conditions at factories in China, that’s pretty much how these factories were back then for kids. Crazy! “History never repeats itself, but it does often rhyme”

A rank of precarious, angry, and impoverished workers rapidly growing across the country; new forms of technology, control, and production bringing advantages to a few at the expense of the many; a detached, vain, and despised leader at the helm: the comet had dimmed for the summer, but it was about to burn brighter than ever.

A must-read!

For anyone interested, the author Brian Merchant also has a newsletter + podcast of the same name. That’s how I came across the book.

That made no sense. The valid values for guestOrExternalUserTypes should be one or more of of none, internalGuest, b2bCollaborationGuest, b2bCollaborationMember, b2bDirectConnectUser, otherExternalUser, serviceProvider, unknownFutureValue according to the documentation.

Looking at one of the policies it had the following selection in the “Exclude” section:

This wasn’t any PowerShell or API shenanigans either, as the Entra ID portal too showed the same. I could have sworn this used to show text instead of numbers…

I couldn’t find any info on where this number was coming from. The modifiedProperty value where this JSON is located comes from the service in question, so the docs didn’t have anything either.

To figure out what’s happening I created a new policy and started fiddling with the values.

First I selected just one:

This resulted in "excludeGuestsOrExternalUsers":{"guestOrExternalUserTypes":2, ...}

Then I unticked that and selected the second option.

Weirdly now I get the text.

I made one more change:

And this time it’s numbers. Huh?!

Then I realized something… here’s what I see in the Audit Logs in the portal. Notice that for each addition/ update there’s three set of entries.

I should either (obviously) focus on the “Add conditional access” and “Update conditional access” entries, or “Add policy” and “Update policy” entries. In my PowerShell code I was only looking at events generated by the “Conditional Access” service, so I was only seeing “Add conditional access” and “Update conditional access” entries, but here in the GUI I first looked at “Add conditional access” and next time looked at “Update policy” instead of “Update conditional access”.

Silly me! (In fairness, the “Update conditional access policy” entries are generated last, and I was just looking for any entry with an “Update” in it…)

Looking at the correct entry for the first change I made, I see numbers:

Cool. Time to put this down in a table:

So that explains the 63. If all of the above are selected, then the sum of these numbers is 63.

Wrote a little PowerShell function to translate the number into the selections:

function TranslateNumber-ToExternalGuest {
    [CmdletBinding()]
    param(
        [Parameter(Position=0,Mandatory=$true)]
        [int]$InputNumber
    )

    $externalUsersHash = @{
        1 = "Local guest users" 
        2 = "B2B collaboration guest users"
        4 = "B2B collaboration member users" 
        8 = "B2B direct connect users"
        16 = "Other external users" 
        32 = "Service provider users"

    }

    if ($inputNumber -in $externalUsersHash.Keys) { 
        $guestSelections = $externalUsersHash[$inputNumber]
        
    } else {
        $guestSelections = foreach ($number in 32,16,8,4,2,1) {
            if ($inputNumber -ge $number) { 
                $externalUsersHash[$number]
                $inputNumber = $inputNumber - $number

            }
        }
    }

    $guestSelections
}

Wanted to capture two screenshots from there.

This is how enrollment works for Android phones

And this is how it works for Android AOSP

This puts into pictures what I saw in the logs in the previous posts.

The Company Portal app is no more. Instead, what it used to do (register in Entra and enroll in Intune) is now done by the Teams app (which is made up of the new Authenticator app and something called an AOSP app).

Here is a comparison of the username password flow between Android and Android AOSP based on my testing past few days

Android	Android AOSP

Feel free to ignore the comments as I copy pasted from the previous posts, key thing is what apps and resources are in play.

This was not unexpected because Microsoft is in the process of moving Teams phones from Android to Android AOSP. Details can be found in this blog post and my phone model’s latest Android firmware is on the list of supported devices.

This is a good opportunity though for me to capture the Entra ID sign-in logs for that process.

Firmware 122.15.0.243 (Android AOSP)

• Firmware Version: 122.15.0.243
• Hardware Version: 122.1.0.0.0.0.0
• Microsoft Intune Version: 25.02.1
• Authenticator Version: 6.2505.3166
  • This is new, is a part of Android AOSP.
• Teams Version: 1449/1.0.94.2025165302
• Admin Agent Version: 1.0.0.202505080136.product

This firmware is from September 2025.

Device Code flow when Android is upgraded to Android AOSP

As part of the enrollment process first the device gets enrolled as Android Device Admin, then the firmware is upgraded to Android AOSP, and it is re-enrolled with the Android AOSP enrollment profile. Just mentioning this because you will see the device in Entra ID with the name <upn>_Android_<date> for a while and then it is renamed to <upn>_AndroidAOSP_<date>. On Intune side though, I think the Android device is un-enrolled and re-enrolled coz when I click on the older entry I get a device not found. That entry disappeared after a few mins so I couldn’t dig around much.

Logs (oldest entries at the bottom – read from bottom to top):

(contd.) (oldest entries at the bottom – read from bottom to top)

There’s more like this from Microsoft Teams and Microsoft Teams Services.

Adding the Device Name too to the output so we can see how that changes (oldest entries at the bottom – read from bottom to top):

(contd.) (oldest entries at the bottom – read from bottom to top)

Username password flow when Android is upgraded to Android AOSP

I couldn’t test this scenario as there’s no way to downgrade the device.

Username password flow

This is when I reset the device and enroll afresh while the phone is on Android AOSP.

The initial screen is as before, where I can either “Refresh code” or sign in to the device. I went with the latter. Entered my email address, password, did MFA, and then got the following:

Clicking “Register” here kicks off the process.

This takes ages (a minute or two) and finally I am in.

Looking at the logs, here are the logs from yesterday with Android and username password flow (oldest entries at the bottom).

Contrast this with Android AOSP (oldest entries at the bottom):

Maybe something amiss with the KQL I am using, the logs don’t seem to be in order. But the key difference is, with Android AOSP: Microsoft Teams is doing most of the work, talking to Device Management Service etc. And when this interaction happens, it triggers the device registration etc.

Reading from down, the first Microsoft Teams <=> Device Management Service with an error code 50097 is not a Conditional Access failure. Rather something else is throwing the error. The message is: Device Authentication Required - DeviceId -DeviceAltSecId claims are null OR no device corresponding to the device identifier exists.

The next interaction with error code 50074 is from our Conditional Access policies requriing MFA.

The one after that with error code 50076 is part of the MFA requirement. The error is: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access the resource.

And then we get error code 50129 which is Device is not Workplace joined - Workplace join is required to register the device. The logs don’t say Conditional Access is triggering this, but I see our policies requiring Compliant Devices are failing – so I guess this is due to Conditional Access, but maybe also not. It could be like 50097 above.

This repeats 3 more times, with the fourth attempt registering the device.

Then Intune Company Portal picks in and does Intune Enrollment. At this point the device name is the default YealinkMP56.

Anyways, key takeaway is Microsoft Teams is driving things.

The logs continue, and I was surprised to see the Device Admin agent app again. (Oldest entries are at the bottom, read from bottom to top).

Device Code flow

Reset the phone, and tried with Device Code flow. This should be a quick win, right? Nope! It failed like this:

The logs are short this time (read from bottom to top).

This makes no sense. Things seem to have succeeded as per the logs. Intune enrollment did happen, and what finally failed is “Device Admin Agent” failing coz the device isn’t compliant. If I expand the entry, the device state is “Managed” – so it is Intune enrolled – but not yet Compliant. I double check in  Intune too, and indeed the device is enrolled! What gives?!

Maybe its just a matter of time? So I powered off and powered on the device like any good IT person, hoping the phone would just realize it is enrolled and contine from there. Of course it did not! After reboot the phone was back to the sign in page. Undeterred, I tried the device code method again (I didn’t reset the device this time) – and no surprises, this time it worked!

The only consistent thing is that nothing’s consistent. Always expect surprises. Why did it work this time, who knows?!

Did it create a new device in Intune/ Entra ID? Nope! I signed in and it took the previously enrolled device. So I was right – the enrollment did happen and it was just a case of the device not knowing it, and when I signed in the two got linked. To confirm that no enrollment happened, I took a look at the logs:

Downgraded to Firmware 122.15.0.234 (Android AOSP)

I was surprised but downgrading the firmware worked. Maybe coz I did to the version just one prior to the existing one, or maybe things are different with the AOSP firmware.

Only tried the Device Code flow. Same as before, it didn’t work. The device is Intune enrolled, but the phone throws an error.

Looking at the logs (read from bottom to up) things look a bit different because I don’t see any obvious failures like from Teams Device Admin. And there’s just one entry after the device is Intune enrolled, after which things just stop.

My hunch is that this is something to do with the firmware and delays. But that’s just a hunch.

Back to Firmware 122.15.0.243 (Android AOSP)

What else can I try? I upgraded the firmware back to the latest AOSP one I was on (which is where I began this post) and tried again. No muy bueno, it still fails.

However, I had another idea.

Remember it fails on this screen:

So I put my email address in and clicked “Sign in”. There was no password prompt, but I got the prompt to register my device (which I previously encountered in the username/ password flow).

Clicked “Register” there, and it errored and put me back to where we began.

Weirdly, now Intune doesn’t even show the device name registered properly.

Entra too has the default name of YealinkMP56. So unlike the attempt before where the device enrolled in Intune, looks like that didn’t happen either.

This is so so weird! I seem to be in a loop like yesterday where things do random behaviour. Take a look at these logs – there’s no Intune enrollment happening! And all the failures at the end are because the device isn’t compliant coz it isn’t enrolled in Intune.

Interestingly, I saw an alert email pop up about more Intune issues that got resolved, so maybe I am just unlucky like yesterday?

This has nothing to do with Intune enrollment though.

At this point I am stuck in the loop so reset phone and let’s try again…

And voila! It worked. Yeah.

At this point I don’t care, I just want this to end. I am guessing the Intune issue did have some impact, but I don’t know and I don’t care. It was definitely coincidental that both yesterday and today when things failed there were health alerts; although yesterday’s was more obvious in that username password enrollment too failed, while today it was just Device Code.

Maybe it was just a matter of waiting.

Or the wind blowing in the right direction outside.

Who knows…

Anyways, I can finally collect the logs from a successful Device Code flow enrollment.

But first, the logs from earlier when Device Code failed on this firmware (read the entries from bottom to top).

I was surprised there that Teams Device Admin agent failed and that the name hadn’t changed. The device was enrolled in Intune, Conditional Access was seeing it as Managed, but it wasn’t in a Compliant state yet. The name hadn’t changed, but that too could be put down to a delay in things updating.

I thought this Teams Device Admin failing is what broke things. But I was mistaken, as I see it happening now too but things proceed past it (read the entries from bottom to top).

Even though Teams Device Admin agent failed, that didn’t stop things. When it failed the device is enrolled into Intune but wasn’t Compliant yet – that’s why it failed (same as before – then too the device was Managed but not Compliant yet).

And yet in the very next entry, the device name has changed and is now Compliant. This is what was breaking earlier.

In the logs there’s just a few milliseconds difference between these two entries. So something in the backend must have been broken earlier, because of which it didn’t proceed to the next steps.

There’s a few more entries in the log, and we can see things proceeding and eventually succeeding.

Also, just to call attention to it again, with Android AOSP it’s “Microsoft Teams” that does most things.

Username password	Device Code

That’s it! I am outta here.

Link to part 4

Update (the following day): Today there is a health alert for Intune AOSP devices.

So there must have been some intermittent issue past few days which is now gotten worse/ noticeable. Just my luck!

Firmware 122.15.0.107

This firmware is from December 2022. Here is what the admin page shows post-upgrade:

Things are a bit different now when powering on the device. You get a page like this:

Device Code flow

Click Refresh code to get a code. Then on my computer I went to the Device Login page, entered the code, did MFA, it asked me for a password followed by MFA again, then a prompt like this:

Clicked “Continue” and it signed me in.

Interestingly, the phone failed though.

“Couldn't connect to Workfplace Join. Try again, or contact you admin.”

Looking at the logs, I can see tha things are different this time (oldest entries at the bottom – read from bottom to top).

For one, we start with the Authentication Broker app this time, rather than Company Portal. So the page showing me a code is not the Company Portal app any more. This explains why Device Code worked, and why the message in my browser confirming the app I was signing into also showed the Authentication Broker.

The logs show a failure for this due to requiring MFA, and there’s a bunch of these which is probably why I got prompted for MFA twice.

The first failure message in the screenshot was “Credentials have been revoked due to the following reasons: SSO Artifact is invalid or expired, Session not fresh enough for application, A silent sign-in request was sent but the user's session with Azure AD is invalid or has expired.“, followed by “For security reasons, user confirmation is required for this request. Please repeat the request allowing user interaction.”

Neither of these messages are due to Conditional Access, so I am not sure what is going on. And confusingly, after these there was a final success message. So why did it fail?

I decided to try again in case it was a temporary error.

Clicked “Refresh code” on the phone, got a new code, and entered it in the browser. Prompted for password again, MFA, was shown the confirmation message asking if I am signing into Authentication Broker, and again while things succeeded in the browser it failed on the phone. Oh well.

Again the logs give a “For security reasons, user confirmation is required for this request. Please repeat the request allowing user interaction.” message and eventually succeeds.

One reason for this error is unsupported Conditional Access policies. And sure enough, looking at the supported Conditional Access policies for Teams phones it specifically says Device Code flow should not be blocked.

I still don’t see how it matters though, coz Conditional Access is not blocking anything in my case (as per the logs at least). Ideally, I should exempt myself altogether from the Device Code blocked flow and test, but I don’t want to. Plus, I know this issue gets fixed later (teaser for my later blog post! ) so time to move on and try the password flow.

Before I move on, for future reference here is a screenshot of the failure I got.

Everything looks alright, except for the error. And in the “success” entry just after this, it looks like the device hasn’t actually registered… so something failed.

Username password flow

This time I clicked “Sign in to this device” on the phone instead of doing a “Refresh code”.

That gives the familiar sign in page from the Company Portal. I enter my email address, password, MFA, and we are off to the races!

After signing in:

Again that error from before. I clicked “Try again”. This time it worked!

Yay! And finally, a glimpse of the Company Portal apps screen for some reason.

Followed by some more screens from Teams. On the screen where there’s a “Sign in” button it signs in automatically.

And we are in! After this I am shown the Teams phone UI.

Looking at the logs (oldest at the bottom – read from bottom to top):

Just after the MFA prompt, when Intune Company portal is talking to Windows Azure AD (the first of the green shaded section), the device has successfully registered. (See the screenshot just after the one below where I can see this).

(contd.) (oldest entries at the bottom – read from bottom to top)

You can see Teams Device Admin also getting involved with Device Registration.

The only difference in the above output vs the Device Code one which failed is that after the Authentication Broker talking to Device Registration Service, we have Intune Company Portal talking to Windows Azure AD. I wonder if something is failing there. Here is what that entry looks like:

Firmware 122.15.0.166

This firmware is from March 2025. It’s the last of the Android firmware for this phone. I don’t expect much changes, but I upgraded to it to have the latest results just in case.

Details:

On the phone, the sign in page is same as before.

Device Code flow

Magic! This worked.

Not adding any screenshots as it’s exactly as what I put above for the username password flow with the previous firmware. Only difference is that the Company Portal picked up the firm logo and theme instead of the default blue.

The logs look better too (of course) (oldest entries at the bottom – read from bottom to top):

Key takeaway #1: firmware matters. Nothing changed on the Conditional Access policies or user account between the two firmware versions, but in the older one Device Code flow failed for no apparent reason, but in the newer one it worked. I think this point bears emphasising, because Conditional Access is usually blamed for a lot of things, but it isn’t always the culprit.

Key takeaway #2: you can block Device Code flow in general but only need allow it for the Device Registration action and exclude Teams Phone devices, and Teams Phones enrollment will work. The Microsoft docs make it sounds like you need to allow it carte blanche for the user, but you don’t really need that.

A quick sidebar on blocking Device Code flow for all, except Teams Phones

The Device Registration action is under Target resources > User actions > Register or join devices. But you can’t exempt it coz the only option available is to include it.

Instead, apply the policy to “All Cloud Apps” but exclude “Device Registration Service”.

I am not sure what the difference is between the action and the app. I’d imagine the action is just a convenience thing and that it actually calls upon the underlying app, so that’s why excluding the app does the trick.

However, excluding only Device Registration Service from the Device Code block policy doesn’t help when it comes to Intune enrollment or using Teams etc. That’s because all these continue to be a part of the Device Code flow. Here’s a repeat of the screenshot I put above. Notice the transfer method is still deviceCodeFlow when it comes to Intune Enrollment, Teams Service, etc.

So we need to exclude Device Code flow for these too. The neat thing is since these steps are after the device has registered, we have more details of the device available to play with. Thus, we can exclude for instance devices with name “Yealink MP56” from the Device Code block policy, and so Device Code flow will continue working after the device has registered and when it tries to enroll in Intune etc.

Note: I am not saying that this is what one should do, all I am saying is that if one devices to block Device Code flow (is a good thing to do), then it must be exempted either for Teams Phone based on the users or some other criteria. Excluding for Teams Phone users doesn’t make sense because then these users can use Device Code flow for anything; so a better idea is to be more fine grained. Excluding based on the device display name or manufacturer is a compromise, and it will need some work as new models and manufacturers are introduced.

Username password flow

Interestingly, after successfully enrolling as above, I signed out of the device and also deleted it from Entra ID. Then I tried the username password flow, and that failed immediately after prompting me for MFA.

“Couldn’t connect to Workplace Join. Try again, or contact your admin”. Weird.

So I reset the device to factory settings and tried again (resetting to factory settings does not downgrade the firmware btw).

Surprise, now it worked!

It’s very different to the Device Code flow. I wasn’t expecting that to be honest.

(contd.) (oldest entries at the bottom – read from bottom to top)

As you can see there’s lot more stuff happening!

Link to part 3

What follows below is some additional issues I encountered. They got resolved by themselves in the end, and all I can attribute them to is some Intune outage on Microsoft’s side. I took the effort of writing notes and putting screenshots, and didn’t want to delete them all so here they are. Feel free to skip.

Frustrations

I reset the device one more time and did a Device Code flow authentication (just for kicks!) and now I got the “Couldn't connect to Workplace Join. Try again, or contact your admin” error I previously received with username and password. Weird.

A second reset didn’t make a difference either. Interestingly, the logs show similar messages as what I received with the very first/ default firmware when Device Code flow was failing.

So I rebooted the device and tried, and this time it went further but failed with a different error.

This time even though I was getting the same “For security reasons, user confirmation is required...” errors as before, things were proceeding further (notice the SUCCESS from Intune Enrollment).

So I took a look at Intune and sure enough things reached Intune and failed. In fact, interestingly, I had only two enrollment failures under my account – one from now, and one from earlier in the day when I tried with the original firmware.

Vague error though.

I double checked the phone firmware with what I had noted down earlier – no change. And yet something was failing.

The weird thing, moreover, was that each time I reset the device and try I was getting a different error. On my 3rd attempt it seemed to again proceed as usual but then dropped me at this sign in page, and then when I tried to sign in via Device Code nothing happened.

Aaargh!

On my 4th attempt, things were at least consistent in that I got the same error as above. So I decided to dig deeper into the sign in logs.

Interesting thing is even during this attempt the device is getting registered in Entra and then failing. And… it is failing due to our Conditional Access policies.

Weird (that word again!) thing is this error makes sense. At this point the device has only registered in Entra ID and it isn’t Intune enrolled, and so when Teams is trying to access the Teams Services resource it naturally fails because we have Conditional Access policies in place that require the device to be compliant. If the device had enrolled in Intune after device registration, this error wouldn’t have occured.

Contrast this to the logs I captured earlier when Device Code flow worked:

Here the device does Intune enrollment, as part of which it does Device Registration, and thus things work. But now the phone wasn’t doing Intune enrollment at all. I have no idea why!

Interestingly, in one of the previous failed attempts it was doing an Intune enrollment. This is all so confusing!

(Btw, after I took the above screenshot where no Intune enrollment was happening, I saw more logs come through. Here too no Intune enrollment is happening, but the Teams Device Admin agent is trying to do something. I wonder if the phone got corrupt somehow).

What else? 

So far I had reset the device to factory settings multiple times. I had also tried resetting user data (that was another option in the admin UI) but it didn’t help either. One thing I wanted to try next was reinstall the firmware. The first time I upgraded to this version of the firmware it never prompted me to change the admin password of the device, but ever since then whenever I’d reset the firmware it prompts me to change the password. Not a big deal in itself, but I felt this wasn’t putting the device back to the original state at which it was working. It never asked me to change the password the first time I moved to this firmware, so why was it always asking now when doing a reset. Clearly that wasn’t a “reset” enough? (wishful thinking…)

For this phone at least, trying to upload the firmware again didn’t work as the phone wouldn’t accept it. Neither did trying to downgrade to a previous version. I had nothing else left to do.

Out of ideas, I thought let me try what happens with the username password flow, coz clearly that should work? But nope, that too fails with the same error! Madness!!

At this point I gave up for the day. Something’s broken somewhere, and I’ve had enough for today!

Guess what, it works now! Wasted about 3 hours yesterday evening/ night troubleshooting this. At least I am wiser in the art of troubleshooting I suppose?

Interestingly, as part of the enrollment the firmware too got updated. We are now at:

The presence of Authenticator, plus the fact that I was on the latest Android firmware available from Yealink got me thinking maybe the device is now on Android AOSP, and sure enough it is. Nice!

The closest I can find from Microsoft as to why enrollment failed yesterday is some alerts about Intune Datawarehouse. This might have been a side effect of that?

This issue started 3 days ago though, but the fix was rolled out around the time I was testing so maybe that’s how they are related? I dunno.

Update (a few hours later): When I logged in to work later, there were reports from others that Teams phone enrolment were failing yesterday. So it looks like there was indeed some issue.

Link to part 3

Firmware 122.15.0.33

This is what the device had out of the box:

• Firmware Version: 122.15.0.33
• Hardware Version: 122.1.0.0.0.0.0
• Company Portal Version: 5.0.4927.0
• Teams Version: 1449/1.0.94.2020111101

Powering on the device greets you with this screen:

You can click the Gear icon on the top right to get into settings to view the IP address and other details. That’s how I then connected to the phone’s admin portal to take a look at the firmware etc.

Clicking “Sign in” opens up the (Intune) Company Portal app.

I can either enter the email address here and click “Next”, or click “Sign-in options” to do a Device Code flow.

Device Code flow

I am not expecting this to work coz we have blocked device code flow firmwide. As a test though, I have an exception for myself for when registering a device, and I want to see what happens.

Clicking on “Sign in from another device” gives me a code. I can enter that in a browser, and as expected it failed.

As expected it fails:

And I can see it in the logs too:

Some things to note:

• The app in question is the Intune Company Portal – expected.
• It is trying to access Windows Azure AD
• Notice the Device Details are a mix of the computer I am doing device login from (the device Id is of my computer, the browser I am using is indeed Firefox, the machine itself is Hybrid joined, but the OS is picked up as Android).
  • There’s no particular significance to this, but it’s worth pointing out because the OS field/ Device Details may not always be accurate. I would have either excepted this to be “Windows”, or the whole Device Details property to be about the Teams phone itself.

Username password flow

Now let’s try the username password flow. I enter my email address, followed by password, followed by an MFA prompt (may or may not happen to anyone else trying this as it depends on your conditional access policies).

Things went weird after this, and I think that’s down to the very old firmware on the device. Nevertheless, here are some screenshots.

First, the company portal tries to sign in.

Then I got this error from Teams, which I clicked “OK” on and tried to sign in again at which point it again launched the Company Portal and tried to sign me in (didn’t ask for credentials this time coz I am already authenticated I suppose). That too gave me some errors.

If I click “Try again” here, it went through the Company Portal steps again but with more success than last time. It got up to the stage where the device was setup, but then balked and took me back to a different sort of Company Portal sign in page.

Clicking “Sign in” here again tried to sign me in via the Company Portal (automatically, I wasn’t prompted for creds) and then it dropped me at the regular sign in page.

Again, I entered my email address and password and went through the drill… and again it looked like it was trying to register my device, but finally failed and dropped me back at this sign in page. At this point I gave up. I suspected the older firmware might not be supported any more.

Here’s what I see in the interactive and non-interactive sign-in logs (oldest entries at the bottom – read from bottom to top).

This coincides with what I saw on the phone itself. Essentially:

• The Intune Company Portal app is what drives things
• It talks to the Authentication Broker to do a Device Registration
• Things don’t work somewhere – not in Conditional Access or Entra ID at least, coz everything is a success here – and that’s probably why things keep retrying.

I figured I should update the firmware and try again. Rather than continue in this post though, I am going to start a new one. I realize this one has too many photos so I don’t want to load it all in a single post.

Link to part 2

Slight issue with that. When I used to do this via the Hue sensor, it would set the correct scene coz the sensor was set to power on the light with a particular scene. Now when I turn it on directly, it just turns on to whatever scene was last set and not a specific one I want.

Figuring out how to do this was a bit more work. Lights don’t seem to have scenes associated with them, but there is a scene API so I started from there.

To get a list of all my scenes:

curl --request GET \
    --url https://$BRIDGE_IP/clip/v2/resource/scene \
    --header "content-type: application/json" \
    --header "hue-application-key: $APIKEY" \
    --insecure

The output of that looks like this:

{
  "errors": [],
  "data": [
    {
      "id": "00d34266-51d6-4c80-83fa-bf0ab36e5c3c",
      "id_v1": "/scenes/tLsH7eKgC2MbSukJ",
      "actions": [
        {
          "target": {
            "rid": "a9871b12-441e-44ba-8554-e458d6c9f65c",
            "rtype": "light"
          },
          "action": {
            "on": {
              "on": true
            },
            ...
          }
        },
        {
          "target": {
            "rid": "4f904f94-7997-4e41-ac43-0635a07472c4",
            "rtype": "light"
          },
          ...
        }
      ],
      "recall": {},
      "metadata": {
        "name": "First light",
        "image": {
          "rid": "ec790a2f-e63e-46cf-8a0f-1dd525e70f66",
          "rtype": "public_image"
        }
      },
      "group": {
        "rid": "baddd0aa-d3cd-4e13-8ddd-627d131f8b18",
        "rtype": "room"
      },
      "speed": 0.626984126984127,
      "auto_dynamic": false,
      "status": {
        "active": "inactive",
        "last_recall": "2025-03-10T17:40:45.090Z"
      },
      "type": "scene"
    },
    {
      "id": "06ab863f-f991-4659-af62-c9b6d4037d48",
      "id_v1": "/scenes/63HZDqdb-RJ0TTGH",
      ....
    }
  ]
}

The scene name can be found in the metadata > name property. What I learnt from some fooling around is that each of these scenes has a rid property which is the room id the scene is associated with. (And the lights themselves are in rooms have so have a rid associated with them, and that’s how you link a scene to a light).

I had some fun with jq. It’s been a while, and while I usually use PowerShell and never had to fuss too much with extracting data from JSON, this was a good excuse to stick with Bash and jq.

I piped the output of the above command into jq like this:

curl --request GET \
    --url https://$BRIDGE_IP/clip/v2/resource/scene \
    --header "content-type: application/json" \
    --header "hue-application-key: $APIKEY" \
    --insecure | 
jq '.data | .[] | { scene: .metadata.name, rid: .group.rid, id: .id }'

The output is a list of scenes and room ids and scene ids.

{
  "scene": "Rolling hills",
  "rid": "baddd0aa-d3cd-4e13-8ddd-627d131f8b18",
  "id": "fdae49d6-cd84-4b00-9f30-b90e65d3bb13"
}
{
  "scene": "Night-time",
  "rid": "baddd0aa-d3cd-4e13-8ddd-627d131f8b18",
  "id": "ffbfe1af-8868-4b39-944b-519763636032"
}

Next I went through the lights I wanted to modify, and found their room Ids.

ALLLIGHTS=(<guid> <guid>)
for LIGHT_ID in ${ALLLIGHTS[@]}; do
    curl --request GET \
        --url https://$BRIDGE_IP/clip/v2/resource/grouped_light/$LIGHT_ID \
        --header "content-type: application/json" \
        --header "hue-application-key: $APIKEY" \
        --insecure
done | jq '.data | .[] | .owner.rid'

At this point I could have just dumped the output of the first command that gives scenes and room ids and ids, and searched for the room ids of my lights. But I wanted to keep things interesting, so I took one of the room Ids and decided to search all scenes for that room id.

curl --request GET \
    --url https://$BRIDGE_IP/clip/v2/resource/scene \
    --header "content-type: application/json" \
    --header "hue-application-key: $APIKEY" \
    --insecure | 
jq '.data | .[] | select(.metadata.name == "<the scene I am interested in>" and .group.rid == "<room id from before>") | .id'

This will return a single id, that of the scene.

Later I realized I have two set of lights in two set of rooms, so I modifed the above to search for both rooms. (Both rooms had the same scene name, so that’s why I don’t search for multiple names).

curl --request GET \
    --url https://$BRIDGE_IP/clip/v2/resource/scene \
    --header "content-type: application/json" \
    --header "hue-application-key: $APIKEY" \
    --insecure | 
jq '.data | .[] | select(.metadata.name == "<scene name>" and (.group.rid == "<room id 1>" or .group.rid == "<room id 2>")) | .id'

Now I have the two scene Ids I am interested in. Time to see if I can turn on the lights with these ids. Each scene Id is for a particular light. (Disclaimer: my situation might be a bit different from anyone else reading this. I have a set of lights that I put into separate “fake” rooms in Hue, so that’s why I am fussing about with rooms. I do this just so I can turn on the bedroom “room” lights without turning on the lights on my desk etc. too even though they are all in the bedroom).

The instructions on turning on a scene aren’t very clear in the API docs. All they have is the following which you send via a PUT request:

So first I tried this:

ALLSCENES=(<guid1> <guid2>)
for SCENE_ID in ${ALLSCENES[@]}; do
    curl --request PUT \
        --url https://$BRIDGE_IP/clip/v2/resource/scene/$SCENE_ID \
        --header "content-type: application/json" \
        --header "hue-application-key: $APIKEY" \
        --data '{ "recall": {"action": "on"} }' \
        --insecure
done

Didn’t work! I got an error:

{"data":[],"errors":[{"description":"error: 'json-schema validation', keyword: 'enum', details: {instanceRef: '#/recall/action', schemaRef: 'clip-api.schema.json#/definitions/RecallFeaturePut/properties/action'}"}]}

{"data":[],"errors":[{"description":"error: 'json-schema validation', keyword: 'enum', details: {instanceRef: '#/recall/action', schemaRef: 'clip-api.schema.json#/definitions/RecallFeaturePut/properties/action'}"}]}

Then I took a look at the scene JSON again and saw the following:

...
      "recall": {},
      "metadata": {
        "name": "<scene name>",
        "image": {
          "rid": "<guid>",
          "rtype": "public_image"
        }
      },
      "group": {
        "rid": "<guid>",
        "rtype": "room"
      },
      "speed": 0.603,
      "auto_dynamic": false,
      "status": {
        "active": "inactive",
        "last_recall": "2025-05-19T11:57:57.032Z"
      },
      "type": "scene"
     ...

Hmm, last status is inactive. So I changed my code to do active, instead of on.

ALLSCENES=(<guid1> <guid2>)
for SCENE_ID in ${ALLSCENES[@]}; do
    curl --request PUT \
        --url https://$BRIDGE_IP/clip/v2/resource/scene/$SCENE_ID \
        --header "content-type: application/json" \
        --header "hue-application-key: $APIKEY" \
        --data '{ "recall": {"action": "active"} }' \
        --insecure
done

Boom! That worked.

Interestingly, you’d think that sending the action as inactive instead of active will turn it off, but that didn’t do anything. I got an error again:

{"data":[],"errors":[{"description":"error: 'json-schema validation', keyword: 'enum', details: {instanceRef: '#/recall/action', schemaRef: 'clip-api.schema.json#/definitions/RecallFeaturePut/properties/action'}"}]}

{"data":[],"errors":[{"description":"error: 'json-schema validation', keyword: 'enum', details: {instanceRef: '#/recall/action', schemaRef: 'clip-api.schema.json#/definitions/RecallFeaturePut/properties/action'}"}]}

Which is fine, I guess. What you want to do is turn off the lights anyway.

Here’s an updated version of my script that turns on or off the lights:

#!/usr/bin/env bash

APIKEY="<apikey>"
BRIDGE_IP="<ip address>"
SENSOR_ID="<sensor guid>"

ALLLIGHTS=(<light guid> <light guid>)
ALLSCENES=(<scene guid> <scene guid>)

if [[ $1 == "enable" || $1 == "on" ]]; then
    echo "Enabling lights"
    
    for SCENE_ID in ${ALLSCENES[@]}; do
        curl --request PUT \
            --url https://$BRIDGE_IP/clip/v2/resource/scene/$SCENE_ID \
            --header "content-type: application/json" \
            --header "hue-application-key: $APIKEY" \
            --data '{ "recall": {"action": "active"} }' \
            --insecure
    done
else
    echo "Disabling lights"

    for LIGHT_ID in ${ALLLIGHTS[@]}; do
        curl --request PUT \
            --url https://$BRIDGE_IP/clip/v2/resource/grouped_light/$LIGHT_ID \
            --header "content-type: application/json" \
            --header "hue-application-key: $APIKEY" \
            --data '{ "on": { "on" : false } }' \
            --insecure
    done
fi

And that’s all folks!

Update (7th Nov 2025): I noticed that whenever I’d lock the screen Hammerspoon wouldn’t always run the script to turn off lights. It could be a time issue I suppose, coz reloading Hammerspoon and then locking the screen does. turn off lights. I am not entirely convinced it’s a time issue coz if I leave the system as is overnight and then login the next day, the script to turn on lights runs.

Maybe I am spending more working than I don’t?

Anyways, slight hack to fix the issue. I added the following to my config:

hs.hotkey.bind({ "ctrl", "cmd" }, "q", function()
    hs.execute("~/desklights.sh disable", false)
    hs.caffeinate.lockScreen()
end)

This causes Hammerspoon to bind to the keys I use for locking the screen, execute the script and then proceed to lock the screen. It’s not ideal coz it doesn’t capture the scenario where I step away for a while without locking the screen and the system goes to sleep and the script doesn’t run.

I run the command as before:

APIKEY=$(pass apiKeys/hue)
BRIDGE_IP="<ip>"
SENSOR_ID="<guid>"

echo "${GREEN} Enabling sensor${RESET}"
curl --request PUT \
    --url https://$BRIDGE_IP/clip/v2/resource/motion/$SENSOR_ID \
    --header "content-type: application/json" \
    --header "hue-application-key: $APIKEY" \
    --data '{ "enabled" : true }' \
    --insecure

The output is a success:

{"data":[{"rid":"77064b38-907d-42ad-a65b-4f22178c3e6d","rtype":"motion"}],"errors":[]}

And querying the sensor shows its enabled too:

curl --request GET --url https://$BRIDGE_IP/clip/v2/resource/motion/$SENSOR_ID --header "hue-application-key: $APIKEY" --insecure | jq

{
  "errors": [],
  "data": [
    {
      "id": "<guid>",
      "id_v1": "/sensors/xx",
      "owner": {
        "rid": "<guid>",
        "rtype": "device"
      },
      "enabled": true,
      "motion": {
        "motion": true,
        "motion_valid": true,
        "motion_report": {
          "changed": "2025-11-04T20:31:09.366Z",
          "motion": true
        }
      },
      "sensitivity": {
        "status": "set",
        "sensitivity": 4,
        "sensitivity_max": 4
      },
      "type": "motion"
    }
  ]
}

But it does nothing, and the app shows that it is indeed disabled!

So much for that.

The lights continue to work though, so I know my API key and things are good. It’s just the sensor and API.

Which got me thinking, maybe I can avoid it? I want the lights to come on when I am working on the Mac. Which means the display is on/ I’ve unlocked the screen. And when the display sleeps/ I’ve locked it, the lights can turn off. So what I really need is a way to trigger my scripts based on the Mac’s state.

Looking for options, I encountered sleepwatcher. (Thanks to ChatGPT actually, it’s way better than Google nowadays for getting search results – unfortunate. And even Gemini, while it suggested sleepwatcher, didn’t suggest any other options like ChatGPT did).

I didn’t use sleepwatcher coz looks like it needs the Rosetta layer on Apple silicon (not a problem but I am trying to keep things Apple silicon only ) plus it seems to be a bit more involved than just downloading and running. I don’t mind things that are a bit more involved, just that the second option ChatGPT suggested was Hammerspoon, which I already use, so I figure I might as well invest more in that.

Turns out there’s a Hammerspoon module called hs.caffeinate.watcher that can watch for system sleep/ wake/ etc. events. Specifically, these ones:

• screensaverDidStart
• screensaverDidStop
• screensaverWillStop
• screensDidLock
• screensDidSleep
• screensDidUnlock
• screensDidWake
• sessionDidBecomeActive
• sessionDidResignActive
• systemDidWake
• systemWillPowerOff
• systemWillSleep

While ChatGPT gave me the code to use to enable this, I wanted to figure out what it does, so what follows is my exploration.

Based on the docs of the module, it looks like I have to create a watcher: hs.caffeinate.watcher.new(fn)

In this fn is the function that will be called. These are Lua functions and they must accept one parameter which is the event type (the ones defined above – systemDidWake and so on). These “event types” are actually constants – i.e. strings – and looks like I must use the full name like hs.caffeinate.watcher.screensDidWake (got from the docs).

So you 1) define a Lua function which does what you need to do (run my script to enable or disable lights) based on the input, 2) create a new watcher instance with the function as input, and 3) start this watcher?

I created a bash script out of my Hue code earlier. This takes an argument and based on it enables or disables the lights.

#!/usr/bin/env bash

APIKEY="<apiKey>"
BRIDGE_IP="<ip>"
SENSOR_ID="<guid>"

ALLLIGHTS=(<lightid1> <lightid2>)

if [[ $1 == "enable" || $1 == "on" ]]; then
    echo "Enabling lights"
    
    for LIGHT_ID in ${ALLLIGHTS[@]}; do      
        curl --request PUT \
            --url https://$BRIDGE_IP/clip/v2/resource/grouped_light/$LIGHT_ID \
            --header "content-type: application/json" \
            --header "hue-application-key: $APIKEY" \
            --data '{ "on": { "on" : true } }' \
            --insecure
    done
else
    echo "Disabling lights"

    for LIGHT_ID in ${ALLLIGHTS[@]}; do
        curl --request PUT \
            --url https://$BRIDGE_IP/clip/v2/resource/grouped_light/$LIGHT_ID \
            --header "content-type: application/json" \
            --header "hue-application-key: $APIKEY" \
            --data '{ "on": { "on" : false } }' \
            --insecure
    done
fi

(Note: Previously I would read the API key via pass, but I had to remove that because Hammerspoon would hang. I think it’s coz pass tries to get my GPG passphrase and fails).

Next, I created a function and put in my Hammerspoon config file:

function toggleLights(eventType)
  if (eventType == hs.caffeinate.watcher.screensDidUnlock or 
      eventType == hs.caffeinate.watcher.systemDidWake) then
    hs.execute("~/desklights.sh enable", false)

  elseif (eventType == hs.caffeinate.watcher.screensDidLock or 
          eventType == hs.caffeinate.watcher.systemWillSleep or 
          eventType == hs.caffeinate.watcher.systemWillPowerOff or 
          eventType == hs.caffeinate.watcher.screensDidSleep) then
    hs.execute("~/desklights.sh disable", false)
  
  end
end

The function looks for event types that are do with the screen unlocking or the system waking and runs the script with the enable parameter; and for even types that are to do with screen locking or system sleeping or system powering off or screens sleeping it runs the script with the disable parameter. This makes use of hs.execute()  which takes as input the script & its parameters, and a boolean value that determines if the command should be executed in the user’s login shell or not. In my case I don’t want it to, so I set it to false.

And finally, I created a new watcher and started it.

local lightsWatcher = hs.caffeinate.watcher.new(toggleLights)
lightsWatcher:start()

Then I reloaded my Hammerspoon config, locked and unlocked my screen to test, and the lights turned off and on as expected. Awesome!

Before I end, while Googling on some of the issues I encountered (the bit where Hammerspoon used to hang coz of the pass command in my script) I encountered a blog post and StackOverflow post where others have done pretty much what I did above. That’s also from where ChatGPT gave me its suggestions (esp. the StackOverflow post which gives many more suggestions)… so credit where credit is due!

Update (a few hours later): See my next post for a follow-up.

The user in question was indeed enabled and licensed. Also, interestingly, the user Id in the error didn’t match that in Entra ID (but then I guess it must be the Id of the object in Power Platform itself).

Even though my colleague got an error, when he looks at the “Share” pane the user is added there. But the user still can’t access the app.

Googling on this gave such amazing forum posts as this one stating the obvious. But I put my thinking cap on and tried to get to the bottom of the issue.

If I create a dummy app and share it with the user, it works. But it wasn’t working or my colleague with his app.

The user in question was present in the environmnent under the list of users. But I noticed that the user didn’t have any Power Platform environment role assigned to him and I wondered if that mattered. My dummy app was just a new canvas app in the Personal Productivity/ Default, but my colleague’s app connected to SharePoint etc. and in an environment with Dataverse enabled. I know the “Basic User” role usually matters, so I took a look at that role in the Personal Productivity environment and he had that (not just him, everyone who had access to the environment had the role). So I granted the same role to him in the other environment, and now sharing works! (And for good measure I also granted that role to everyone who had access to the environment – which you can find by clicking “Edit” on the environment in Power Platform admin centre).

What a red-herring of an error!

Inevitably a follow-up question is whether I can add it to the custom apps section as that will somehow bring the app into the App Protection policy umbrella. This is a mistaken suggestion and doesn’t work; and lest anyone think this blog post is me dissing upon those who come with such a suggestion, let me assure you that I too used to be in that group until last year or so.  No judgement here!

The custom apps section is meant for custom in-house developed apps, or line-of-business apps. It is not meant for you to find the bundle id of an app not in the default list of apps, add it there, and then things will magically work! This is the misunderstanding and the Microsoft’s documentation too makes this clear:

Custom apps are LOB apps that have been integrated with the Intune SDK or wrapped by the Intune App Wrapping Tool.

So if an app is not supported by default by the App Protection policies, there’s not much we can do. There’s no blanket way to add the app, but workarouds might exist. For instance, I had a request to add ChatGPT to one of our App Protection policies so users can copy-paste into it, and the app doesn’t supprot App Protection policies so I couldn’t add it. As an alternative I suggested publishing it as a web-clip that opens in the managed browser.

This adds a link to ChatGPT web on the home screen to the users it is assigned to. Clicking it will open ChatGPT web in a managed browser, which is under App Protection, and so one could copy paste into ChatGPT here to initiate a conversation and then go to regular ChatGPT to continue there. Not ideal, but that’s an example of a workaround.

Another option is to tweak the number of characters that are allowed for copy-paste (which works in this scenario as the request was for copy-paste). The default value is 0, which means no copy paste is allowed if the policy is set to block; but we can set a number to allow that many characters. The limit seems to be 65535 characters.

My objective here is simply to see if I am even passing inputs in correctly! At this point I am very new to KQL functions so we are talking basics here.

Here’s what I did. I created a new KQL query like this:

let blah = datatable (Blah1:string, Blah2:string) [
    "111", "222"
];
blah
| extend UserInput = Users

Then created a function out of it, and gave that function a single input called ‘Users’.

And now I can call the function in one of these ways:

// this way
RakTestFunc1(Users="rak")

// Or this way
RakTestFunc1("rak")

And I can see the input parameter in the output.

Seems a long winded way to do this, but until I learn of a better way this works I suppose.

For info, here’s what I am doing. First I create a datatable. Why? Because KQL outputs are tables, and I figure I must start with a table so I can add some data to it. I couldn’t think of any other way, so I created a new dummy table. It doesn’t even need the two columns I put in there, just one is fine.

let blah = datatable (Blah1:string, Blah2:string) [
    "111", "222"
];

Then I output this table and extend it by adding a column that shows my input.

blah
| extend UserInput = Users

The ‘Users’ above is my input. It will appear as an error in the console, but we can ignore that because the parameter is set in the function definition.

Ok, next steps. I want the function to have two inputs – a timespan and a string. How do I output these?

Here’s the new KQL:

let blah = datatable (Blah1:string, Blah2:string) [
    "111", "222"
];
blah
| extend TimeRangeInput = TimeRange
| extend UserInput = Users

Add that paramter to the function defintion (click Save and it will open up the dialog box again to add/ remove parameters).

Now if I run the function, I can see what happens:

// Do one of these, as before
RakTestFunc1(Users="rak")

RakTestFunc1("rak")

As you can see, it’s picked up the default.

If I change the input, the output changes:

RakTestFunc1("rak", 12h)

Now I want to change ‘Users’ to be a dynamic type.

Interestingly, once I did that and saved, it changed to a cast.

Things work if I provide an input.

RakTestFunc1(dynamic(['rak']), 12h)

But fail if I don’t provide an input (this is what I had set out to troubleshoot initially, which is why I was creating this dummy way of identifying the inputs passed to a function).

RakTestFunc1(12h)

I get an error: Cast operator: dynamic casting expects string type values

This stumped me for a while and there was nothing I could do to get it working by using the default parameter value if I skipped it.

Finally I found out what to do. It looks like if I am skipping parameter values, I must mention what I am passing.

If I modify the above invocation to be this:

RakTestFunc1(TimeRange=12h)

Now it works and picks up the default!

And if I skip both parameters, that works too.

RakTestFunc1()

What if I want the default to be empty? I changed it to dynamic("")

That works too.

Does that comes across as an empty value though? I modified the underlying function thus:

let blah = datatable (Blah1:string, Blah2:string) [
    "111", "222"
];
blah
| extend TimeRangeInput = TimeRange
| extend UserInput = iff(isempty(Users), "==empty==", Users)

Yup, that works.

That’s all!

Since my desk is in our bedroom, and I don’t want the sensor to be active during weekends, I wanted an easy way to disable it on weekends and enable it after weekends (or maybe not enable it, I think I’ll enable it manually depending on whether I am actually working or not etc).

Yes I can do this via the app but it’s a bother and I wanted to just set and forget it. So I took a look at the Hue API.

First things first, you need the IP address of your Hue Bridge. I got that from the app. Then, you need to create an API key. The getting started section of the Hue API docs has instructions on creating this. I did that, put the key into pass and now I am ready to go.

# Once the API key is in pass I can refer to it thus (apiKeys/hue is the name of the secret)
APIKEY=$(pass apiKeys/hue)

# Also set the bridge IP in a variable
BRIDGE_IP="192.168.200.200"

The /resource/motion endpoint is what deals with sensors. To query it I do:

curl --insecure --request 'GET' --header "hue-application-key: $APIKEY" --url "https://$BRIDGE_IP/clip/v2/resource/motion"

I must use the --insecure switch due to certs (it is a self-signed cert). Also, to make the output readable, one can pipe it through jq:

curl --insecure --request 'GET' --header "hue-application-key: $APIKEY" --url "https://$BRIDGE_IP/clip/v2/resource/motion" | jq

The output is a list of sensors:

{
  "errors": [],
  "data": [
    {
      "id": "72164b38-907d-42ad-a65b-4f22178c3e6d",
      "id_v1": "/sensors/47",
      "owner": {
        "rid": "20d706c2-1a05-4ef6-8a18-cdee0cf42b23",
        "rtype": "device"
      },
      "enabled": false,
      "motion": {
        "motion": false,
        "motion_valid": false
      },
      "sensitivity": {
        "status": "set",
        "sensitivity": 4,
        "sensitivity_max": 4
      },
      "type": "motion"
    }
  ]
}

The id is what I need. Currently it is disabled, as can be seen from "enabled": false. I stored it in a variable SENSOR_ID.

Now, enabling it is simple:

curl --insecure \
     --request 'PUT' \
     --header "hue-application-key: $APIKEY" \
     --header "content-type: application/json" \
     --url "https://$BRIDGE_IP/clip/v2/resource/motion/$SENSOR_ID" \
     --data '{ "enabled" : true }'

I must 1) change the request method to PUT, 2) set content-type headers for JSON, 3) modify the URL to include the sensor Id I previously got, and 4) send a JSON data that sets it to enabled.

Disabling is similarly easy, just change to false.

curl --insecure \
     --request 'PUT' \
     --header "hue-application-key: $APIKEY" \
     --header "content-type: application/json" \
     --url "https://$BRIDGE_IP/clip/v2/resource/motion/$SENSOR_ID" \
     --data '{ "enabled" : false }'

So now I can put each of these into separate files and setup a cron job to run the disable file just before the weekend. (The cron snippet below disables the sensor at 7pm every day; and enables it at 8am every weekday).

# m h  dom mon dow   command

00 08 * * 1-5 /path/to/sensor_enable.sh
00 19 * * * /path/to/sensor_disable.sh

Next, I also wanted to turn off or on the lights affected by the sensor. Coz I realized that say I was working late and the sensor gets disable at 7pm via the above job – the lights now continue to stay on coz there’s nothing to disable them. So I must also add some code to disable the lights when disabling the sensor.

I have two lights together in a group, controlled by the sensor. The lights are in fake room of their own. So I ran the following command to first find the room details:

curl --insecure --header "hue-application-key: $APIKEY" --request 'GET' --url https://$BRIDGE_IP/clip/v2/resource/room | jq

One of the entries looks like this:

{
      "id": "baddd0bb-23cd-4e13-8ddd-627d131f8b18",
      "id_v1": "/groups/82",
      "children": [
        {
          "rid": "ef2f1315-7c24-4470-8d54-126026083250",
          "rtype": "device"
        },
        {
          "rid": "c7109087-2324-4ddb-9496-0b285ca87d5a",
          "rtype": "device"
        }
      ],
      "services": [
        {
          "rid": "1de1ee19-edd7-407c-8358-1dd1cc972143",
          "rtype": "grouped_light"
        }
      ],
      "metadata": {
        "name": "Desk",
        "archetype": "office"
      },
      "type": "room"
    },

This is the room. You can see the group lights in there, with the id for the group.

Controlling a grouped light is the same way as controlling a light. Here’s what I did:

curl --request PUT \
     --url https://$BRIDGE_IP/clip/v2/resource/grouped_light/$LIGHT_ID \
     --header "content-type: application/json" \
     --header "hue-application-key: $APIKEY" \
     --data '{  "on": { "on" : false } }' \
     --insecure

The above snippet turns it off; change the false to true to turn it on.

I added this code to the same script as disabling the sensor, and now it disables the sensor and turns off the light! Yay.

Update (05 Nov 2025): A follow up post here as the API call to the sensor simply stopped working.

As the resident PowerShell person on the incident call, as part of implementing some workarounds I had to add a bunch of IP addresses to a Network Security Group. I was given a text file with a bunch of IP addresses, and my task was to add them all to the NSG as “Deny” for “Inbound” traffic. Here’s what I did:

Connect-AzAccount -Subscription <SubscriptionName>

# get the NSG
$nsg = Get-AzNetworkSecurityGroup -Name '<NSG Name>' -ResourceGroupName '<Resource Group Name>' 

$counter = 1000 # replace with whatever priority the rules must start from

foreach ($address in Get-Content .\ipblocklist.txt | Select-Object -Unique) {
  # construct the rule name
  # todo: the -replace needs improvement via some regex to remove *any* unaccepted characters
  $ruleName = "Deny-" + $($address -replace '\/','-' -replace '\:','')

  # rule name can't exceed 80 chracters
  if ($ruleName.Length -gt 80) { $ruleName = $ruleName.substring(0,79) }
  
  # add the rule to the in-memory copy of the rules
  $nsg | Add-AzNetworkSecurityRuleConfig -Name $ruleName -SourceAddressPrefix $address -Access "Deny" -DestinationPortRange "80","443" -DestinationAddressPrefix "*" -SourcePortRange "*" -Priority $counter -Protocol '*' -Direction 'Inbound'

  # increment the counter
  $counter++

}

# commit to Azure
$nsg | Set-AzNetworkSecurityGroup

Had to piecemeal the code from various sources as the Microsoft Learn website was down so I couldn’t refer to it for the cmdlets and their switches.

Two things the code could do with improving:

• Check if the IP address/ subnet is already in the NSG
• Fix the bit where I construct the rule name to remove any unaccepted characters than just the two I happened to encounter.

Yes, the ending was abrupt, but I loved it. To me that made sense, and it was the only possible ending one could have for a movie like this. The movie wasn’t about the ending, it was about the ordeal leading towards the ending. And whatever happens in the end – be it a false alarm or something devastating – that doesn’t take away from the fear and panic and decision making uncertainity around it. That was the point of the movie.

Not mentioned in the list of apps the “Office 365” app includes, but seems to be implicitly covered in our testing, is the “My Profile” app. If you visit https://mysignins.microsoft.com/ and click on any of “Devices”, “Organisations”, “My Groups” and “My Access” these come under the “My Profile” app.

So requiring a managed device to access the “Office 365” app ensures you can’t access any of these from a non-managed device either. But that still leaves “My Apps” and the https://mysignins.microsoft.com/ page itself, and we were wondering if these can be locked down.

“My Apps” can be controlled. It should appear as an app that can be selected in conditional access, and if it does not one can enable it thus:

New-MgServicePrincipal -BodyParameter @{ AppId = "2793995e-0a7d-40d7-bd35-6968ba142197" }

And then when we learnt that “My Sign-ins” too can be selected, it was great news. (If that app too doesn’t appear, run the same cmdlet as above but use “19db86c3-b2b9-44cc-b339-36da233a3be2” as the App Id. Better still, read that linked post coz that’s where I am copy pasting this info from).

So we naively went and added “My Sign-ins” and locked it too down to managed devices (for a test group of course, not rolling out major changes to the whole firm!). And that’s when we learnt that doing so is not a good idea.

Why? Coz while we were interested in blocking access to the https://mysignins.microsoft.com/ page, a key part of the page is the “Security info” section. I never thought of it as part of the My Sign-ins page as by habit I tend to visit https://aka.ms/mysecurity info for it, but that URL is actually https://mysignins.microsoft.com/security-info and so technically it comes under the “My Sign-ins” app. Which means, with our policy in place, no one can even setup their MFA etc. from an unmanaged device – which is not what you want!

Of course, you do want to lock down who can register MFA, and we too do that by having a conditional access policy that targets the “Register security info” action to require MFA or be from trusted locations, and to get around the chicken-and-egg problem of someone from an untrusted location not being able to register their first MFA we rely on Temporary Access Passes (TAP) – but by locking down the “My Sign-ins” app to managed devices, that basically overrides the TAP policy.

So lesson learnt. We didn’t go ahead with locking down “My Sign-ins”. And like the article suggests, the real use of being able to select “My Sign-ins” in conditional access policies is to exclude it from a policy when you want the policy to apply to “All Cloud Apps” except a few, not to include it.

As part of testing some new Conditional Access policies however, wherein we were limiting users to hybrid joined or compliant devices, I noticed that my test accounts stopped working with the “You can’t get there from here” message.

My machine is hybrid joined, and yet the error message showed it as an unregistered device. The help message points to this Firefox KB article to allow Windows SSO and that was enabled in my case already.

The article also said the account must be added to Windows itself. Under Settings:

I added my test account in there by clicking on “Add a work or school account”. Closed and opened Firefox, and still the account didn’t work.

Thinking this might be an issue with the containers extension itself, I opened up a new tab not in any container and tried browsing with that, and that worked! I was prompted to select an account from all the accounts in the screenshot above, and selecting my test account let me know. So the issue was to do with the containers extension.

Googling on that brought me to this forum post and from there to this GitHub wiki. Looks like this was fixed back in 2023 itself, just not exposed via the UI. Feel free to follow the steps in that wiki, else follow on to see what I did to fix it:

1) Opened up my profile folder.  If you don’t know where that is, click on Firefox help:

More troubleshooting info:

Click open folder to open the profiles folder.

2) Open containers.json. Preferably in an editor like VS Code etc. such that you can format it (optional).

3) Find the entry for the container you are working with and note its userContextId.

4) Then open about:config in Firefox, accept the warning, and type in network.http.windows-sso.container-enabled.<the id>. (There’s a typo in the screenshot below, the 21 should read as 12 coz that’s the correct id).

This creates a new entry.

That’s all! Now if I try and browse via that container, it picks up all my accounts linked to the device, and I can select the one I want to use.

The SSO part doesn’t automagically know what account you want to use (since as far as it’s concerned you are signed in with more than one account) so you have to select the account each time. But that’s not an extension issue, and makes sense. It’s a minor irritation, but I can live with that. (And you encounter this in Edge etc. too if I am signed in to a profile with more than one account – just got to be careful of selecting the correct account each time).

Bonus tip

Since I want this to work with all my containers, and I see that they are in sequential order, what I did is 1) close Firefox and 2) open the prefs.js file in the profiles folder (this is what contains the settings from about:config). I then found the line that I had added:

And I made a bunch more copies of it with numbers starting from 1 – 25 (figured I am on 12 now and I might as well make a few extra for the future). Here’s the lines if anyone else wants to copy paste:

user_pref("network.http.windows-sso.container-enabled.1", true);
user_pref("network.http.windows-sso.container-enabled.2", true);
user_pref("network.http.windows-sso.container-enabled.3", true);
user_pref("network.http.windows-sso.container-enabled.4", true);
user_pref("network.http.windows-sso.container-enabled.5", true);
user_pref("network.http.windows-sso.container-enabled.6", true);
user_pref("network.http.windows-sso.container-enabled.7", true);
user_pref("network.http.windows-sso.container-enabled.8", true);
user_pref("network.http.windows-sso.container-enabled.9", true);
user_pref("network.http.windows-sso.container-enabled.10", true);
user_pref("network.http.windows-sso.container-enabled.11", true);
user_pref("network.http.windows-sso.container-enabled.12", true);
user_pref("network.http.windows-sso.container-enabled.13", true);
user_pref("network.http.windows-sso.container-enabled.14", true);
user_pref("network.http.windows-sso.container-enabled.15", true);
user_pref("network.http.windows-sso.container-enabled.16", true);
user_pref("network.http.windows-sso.container-enabled.17", true);
user_pref("network.http.windows-sso.container-enabled.18", true);
user_pref("network.http.windows-sso.container-enabled.19", true);
user_pref("network.http.windows-sso.container-enabled.20", true);
user_pref("network.http.windows-sso.container-enabled.21", true);
user_pref("network.http.windows-sso.container-enabled.22", true);
user_pref("network.http.windows-sso.container-enabled.23", true);
user_pref("network.http.windows-sso.container-enabled.24", true);
user_pref("network.http.windows-sso.container-enabled.25", true);

That’s all!

New containers

Good to know. When I create a new container and the account I want to use is not listed, adding it via “User another account” will not help.

Because all that will do is add the account within the container, not to Windows itself.

Selected the “Signed in” account above will not work if there are any conditional access policies that need device compliance etc., so one must always remember to go and add it in Windows itself under Settings > Accounts > Email & Accounts.

My thanks to the devlopers of the extension and also for their efforts in fixing this issue.

Enter KQL. We are sending all audit logs to a Log Analytics workspace, so I queried this info that way. This is a very trivial use of KQL, but I am just putting it here for my own reference later on… 

This code gives you everything from AuditLogs in the last 30 days that have “Remove member from group” as the activity.

AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == 'Remove member from group'

This activity name corresponds to what you see in the portal too.

Take one of the result and expand it until you get to TargetResources. The second entry in that has the group that’s affected. Expand that to get to the id, and then right click and filter for that.

This modifies the code thus:

AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == 'Remove member from group' 
| where TargetResources[1].id == "<the group guid>"

Then similarly expand the first entry under TargetResources, select UPN in there, and extend that. (In my case, the already selected entry didn’t have a user being removed… so I found an entry with a user removal).

Finally project just that extended column. The end result looks like this:

AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == 'Remove member from group' 
| where TargetResources[1].id == "<the group guid>"
| extend userPrincipalName_ = tostring(TargetResources[0].userPrincipalName)
| project userPrincipalName_

This gives a list of UPNs removed from the group.

Of course now that you/ future me have read this blog post, just copy paste the above KQL and use it directly. :)

I took a look at the group and found that sharing to guests is still disabled. This can be done via an EXO cmdlet: Get-UnifiedGroup '<group name>' | fl *Gues*

AllowAddGuests : False

Turns out the Set-UnifiedGroup cmdlet doesn’t have an option to toggle this. Got to use Graph API for this, specifically the group settings endpoint. Here’s what I did:

# To get the group Id
$groupObj = Get-MgGroup -Filter "DisplayName eq '<group name>'"

$groupId = $groupObj.Id

# Get the existing settings. Need this for the GroupSettingId. 
$groupSettingsObj = Get-MgGroupSetting -GroupId $groupId

# To allow Guests - body of the request
$params = @{
	values = @(
		@{
			name = "AllowToAddGuests"
			value = "True"
		}
	)
}

Update-MgGroupSetting -GroupId $groupId -BodyParameter $params -GroupSettingId $groupSettingsObj.Id

# To view the setting via Graph after the change
(Get-MgGroupSetting -GroupId $groupId).Values

As per the docs, you need to be a Global Admin or an Exchange Admin (possibly with Application Admin, depending on certain conditions) to do this. And while that seems to be the case with the portal, it looks like one can do some tasks with only the Application Admin role via PowerShell.

In my case I don’t need to deploy new add-ins, only manage who an existing add-in is deployed to.

The instructions for using PowerShell are in this link, but below is what I did.

# Install the module, import it etc. 
Install-Module -Name O365CentralizedAddInDeployment
Import-Module -Name O365CentralizedAddInDeployment

# Login 
Connect-OrganizationAddInService

After that, to get all the available add-ins, one can do:

Get-OrganizationAddIn

And then to get the details of a specific add-in (e.g. publisher, version), one can do:

Get-OrganizationAddIn -ProductId 815b5912-1fb6-44ac-8971-f54600fdd599 | fl *

And then to publish it to users and groups, one can do:

# Add a group...
Set-OrganizationAddInAssignments -ProductId 815b5912-1fb6-44ac-8971-f54600fdd599 -Add -Members "dd3772c5-3b54-48fb-b5a3-c724855f2275"

# Remove a group
Set-OrganizationAddInAssignments -ProductId 815b5912-1fb6-44ac-8971-f54600fdd599 -Remove -Members "dd3772c5-3b54-48fb-b5a3-c724855f2275"

# Add a user...
Set-OrganizationAddInAssignments -ProductId 815b5912-1fb6-44ac-8971-f54600fdd599 -Add -Members "me@mydomain.com"

# Remove a user...
Set-OrganizationAddInAssignments -ProductId 815b5912-1fb6-44ac-8971-f54600fdd599 -Remove -Members "me@mydomain.com"

That’s all!

Interestingly, sometimes the portal too let me do these tasks with the Application Admin role; but not always. I find PowerShell to more consistently work rather than the portal.

In the on-prem world the URLs are of the form https://olddomain.com/app/#/secret/secretId, while in the cloud world it is very similar and looks like https://newdomain.com/app/#/secret/newsecretId. While it’s easy to setup a redirect from olddomain.com to newdomain.com, the problem is that the secretId changes to a new number newsecretId in the cloud, so you can’t just do a catch-all redirect.

I had a CSV file of the old and new secret Ids, and I wondered what I can do with it.

(By the way, side promo of a new tool I discovered recently. SmoothCSV. If you deal regularly with CSVs, and don’t want to open Excel/ LibreOffice for it, nor use a regular text or code editor as that doesn’t look right either, this is the tool for you! Open source and cross-platform).

Azure Front Door

One more thing we wanted to do was have https://olddomain.com/* redirect to a SharePoint Online with some info on the migration for anyone using the old URLs, and so we had setup Azure Front Door for this. It’s a simple rule there to redirect any URLs beginning with https://olddomain.com/ to https://newdomain.com/ and I wanted to piggy back on that to handle URLs beginning with https://olddomain.com/app/#/secret/ differently somehow.

This is where I encountered my first issue, which stumped me for a while. I only realized later what was happening, but by then I had stumbled upon a fix by blindly trying different things to get it working.

Here’s what I did. In Front Door I have two rules:

• Rule 1: If a URL begins with https://olddomain.com/app/#/secret/ send it to a dummy Azure Function I had setup. Stop processing any more rules.
• Rule 2: If a URL begins with https://olddomain.com send it to the SharePoint site.

Rule 2 was the original rule, created as part of the initial requirement. Rule 1 is what I created and put as a higher priority over Rule 1, so I can do my per secret Id redirecting somehow.

Sounds like it should work, but it does not! I never hit Rule 2, I always keep going to Rule 1. I even changed Rule 2 to be a RegEx match, but that didn’t help either.

The fix, in the end, was to match on the URL beginning with https://olddomain.com/app/. That worked, and while I stumbled upon it by troubleshooting and removing parts of the URL to see what minimum works, I wasn’t sure why this was the fix. Nevertheless I moved on to the next part of the problem.

Enter Azure Functions

My idea was to have these URLs be redirected to an Azure Function. I’ll import the CSV file of old and new secret Ids into an Azure Tables, the Azure Function will receive an URL that looks like https://olddomain.com/app/#/secret/secretId from Azure Front Door, I will use PowerShell to extract the secretId, lookup the new value from Table, construct a new URL https://newdomain.com/app/#/secret/newsecretId and send that to the user.

Turns out sending a user a new URL is very easy. From a bit of Googling I learnt that a bit of HTML like this does the job:

<html>
<head>
    <meta http-equiv="refresh" content="1;url=https://newdomain.com/app/#/secret/$newSecretId/" />
    <title>Redirecting...</title>
</head>
<body>
</body>
</html>

What the above does is that it tells the browser receiving the page to do a refresh to the given URL after 1 second. I put $newsecretId above, coz that’s what will change based on the lookup.

In Azure Function, all I need do is the following (these are only snippets, not the whole code):

# Put the HTML from above into a variable; this assumes I have looked up and got a value for $newSecretId already
$html = @"
<html>
<head>
    <meta http-equiv="refresh" content="1;url=https://newdomain.com/app/#/secret/$newSecretId/" />
    <title>Redirecting...</title>
</head>
<body>
</body>
</html>
"@

# Return that
Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = 200
    # This is crucial, without the ContentType the receiving browser will treat the HTML as plain text 
    ContentType = "text/html; charset=utf-8" 
    Body = $html
})

exit

Neat!

But of course, this didn’t work as expected! There wouldn’t be a blog post if it did.

What was failing was the part not in the snippet above. When I receive the redirected URL from Azure Front Door, I wasn’t getting the old secret Id in the link.

A digression

A bit of a digression first.

Typically an Azure Function URL looks like this: https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>/

It is possible to remove the /api/ but by setting the following JSON in the host.json file.

{
    "version": "2.0",
    "isDefaultHostConfig": true,
    "managedDependency": {
        "Enabled": true
    },
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.*, 5.0.0)"
    },
    "extensions": {
        "http": {
            "routePrefix": ""
        }
    }
}

It is also possible to remove the <FUNCTION_NAME> bit from the URL. The official doc tells you how but is incomplete as it only gives you examples of changing <FUNCTION_NAME> to something else. I wanted to remove it though, if possible, and when Googling didn’t help I turned to ChatGPT and from there I learnt that by modifying the function.json file thus, I can achieve it:

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get"
      ],
      "route": "{*path}"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

The "route": "{*path}" bit makes it so that all paths are sent to this Function app. I couldn’t find much documentation on this wildcard property, but I did find some links that explained this property in general (like this one, for instance). Glad I stumbled upon it via ChatGPT!

With this in place I can access whatever is sent to the function via the $Request.Params.path property (the name path matches whatever is puting in the route definition).

Back to the issue

So now I have Azure Front Door redirecting https://olddomain.com/app/#/secret/secretId to my Function App. When redirecting, it will send the browser to <APP_NAME>.azurewebsites.net/ and also include app/#/secret/secretId.

I know the app/#/secret/secretId part will come through, coz I am not setting anything in the Destination path and Destination fragment, so Front Door will send whatever it gets over. This is why I removed the extra bits from the Function URL, coz if I didn’t do that I’d have to put api/<FUNCTION_NAME>/ in the Destination path, and I didn’t want to do that coz there’s no way to add that and have Front Door append whatever it gets. By leaving it blank, Front Door will send everything over.

And yet, in Azure Function, when I examine the path via the $Request.Params.path property, all I see is “app/“. Nothing after that! Odd.

Fragments

And now we come to fragments.

I had seen the word fragment in Front Door, but hadn’t paid much attention. But once I got to troubleshooting why the Function App wasn’t working, I learnt about it. This also explained to me why Front Door wasn’t working with my original URL way above when I first tried it.

You see, when you have a URL like https://olddomain.com/app/#/secret/secretId, the bit after the # is what’s known as a fragment. We typically see them in web pages when used to send the browser to a specific heading/ id tag of a page. Since they are meant to be specific to things within a page, browsers don’t send them to the server. Because the idea is that the browser will only send a request to the page it wants, get it, and then use the fragment to find what it needs.

This is pretty neat from a privacy point of view, coz as you can guess from the URLs above what I am dealing with are some sort of secrets, and clearly the designers of that tool had security in mind and so they put the secret Id part of the URL within a fragment. So no proxy servers or firewalls will ever see the secret Id, all they will see is https://olddomain.com/app/ which presumeably is a JavaScript page, and once that’s got the page itself will be sent #/secret/secretId and it can use that to show the secret Id. Nothing is captured anywhere. (That’s my guess at least on how this is used…)

Unfortunately, this isn’t ideal for me, coz that’s why 1) Front Door never worked when I tried to match on URLs beginning with https://olddomain.com/app/#/secret/ coz it never saw anything after the #, and 2) why Azure Function too cannot see the secret Id. There’s simply no way for me to get it! Aaargh!

A bit of JavaScript to the rescue

But hang on, yes Azure Function can’t see the full URL, but since it’s in the browser, presumeably I can use some JavaScript to get it?

Enter ChatGPT. I asked it for some JavaScript code which can be used to extract the URL from a browser and send to a different URL. It gave me the following code:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8" />
  <title>Redirecting...</title>
  <script>
    (function() {
      const fragment = window.location.hash ? window.location.hash.substring(1) : "";
      const basePath = "${path}";
      let redirectUrl = "/redirect?path=" + encodeURIComponent(basePath);
      if (fragment) redirectUrl += "&fragment=" + encodeURIComponent(fragment);
      window.location.replace(redirectUrl);
    })();
  </script>
</head>
<body>
  <p>Redirecting...</p>
</body>
</html>

Here’s what I can do. Azure Function gets called. It can check what the URL it received it (via the $Request.Params.path property). If the path is just “app/“, then it sends the above HTML to the browser.

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = 200
    # This is crucial, without the ContentType the receiving browser will treat the HTML as plain text 
    ContentType = "text/html; charset=utf-8" 
    Body = $html
})

exit

The browser receives the HTML. Within it is this JavaScript:

(function() {
    const fragment = window.location.hash ? window.location.hash.substring(1) : "";
    const basePath = "${path}";
    let redirectUrl = "/redirect?path=" + encodeURIComponent(basePath);
    if (fragment) redirectUrl += "&fragment=" + encodeURIComponent(fragment);
    window.location.replace(redirectUrl);
})();

The URL in the browser at this point would be https://<APP_NAME>.azurewebsites.net/app/#/secret/secretId (the original URL would have been https://olddomain.com/app/#/secret/secretId which will get redirected by Front Door to https://<APP_NAME>.azurewebsites.net/app/ and then the browser will tack on #/secret/secretId).

The window.location.hash property is the bit after the #. JavaScript can see that coz it is running within the browser in the page that I sent through. The code takes that, and does a redirect to /redirect?path=<whatever is in the URL as a path, in this case /app>&fragment=<whatever it extracted as fragment>.

This too goes over to my Azure Function, as that’s the redirect is relative to whatever page the browser is on! And since the Function is set to receive all URLs sent its way, it is thus called again but this time as https://<APP_NAME>.azurewebsites.net/redirect?path=app&fragment=secret/secretId. Voila!

Extract the Secret Id

Again, the Function can fetch the URL it received it (via the $Request.Params.path property). And if the path is just “redirect/” (coz that’s what we are sending to above), it can extract the parameters that were sent through. These are in the $Request.Query property, so we can get to the fragment by doing:

$fragment = $Request.Query.Fragment

# Get a token
$azToken = ConvertFrom-SecureString -SecureString (Get-AzAccessToken -ResourceType Storage -AsSecureString -ErrorAction Stop).token -AsPlainText -ErrorAction Stop

# Construct headers
$headers = @{
    "Authorization" = "Bearer $azToken"
    "x-ms-version" = "2017-11-09"
    "Accept" = "application/json;odata=nometadata"
}

$uri = "https://$storageAccount.table.core.windows.net/$tableName(PartitionKey='$secretId',RowKey='$secretId')"

$azTableRowObj = Invoke-RestMethod -Uri $uri -Headers $headers -Method GET -ErrorAction Stop

I was half expecting (and not looking forward to) it being a book that bashes AI (or goes the other way and gushes over it). Instead, this book was very neutral. It went into a lot of AI usage (gig economy, data labelling, profiling people, video surveillance etc.) and had a very balanced view of things. Yes, AI is being used for a lot of harm, but it is also used in some good ways. I liked that.

To me AI is a symptom of the overall issue. I think over time our social structures and institutions have been failing – not due to immigation or people etc. but more due to lack of investment in them. Things might have been easier in the past for the rich countries at least due to colonialism and such when money was flowing around, but for a long time that hasn’t been the case and all countries have had to invest from whatever money they have via trade and other means. And this doesn’t always happen, and so over time the quality of things has gone done. Be it from simple things like replacing the person at the other end of the phone when you call your bank or shop – first with cheap workers in call centres in India etc. and later with AI – to bigger things like lack of proper healthcare facilities, doctors etc.

So in all of these cases we look to see how we can get away with the bare minimum. We try and remove the human element from it by trying to codify what is happening – break a task down to a series of steps (algorithms) – and then either hand that off to whoever can do it cheaply, or now AI. But the fundamental issue is that we are trying to convert an analog things (humans and the things they do) into something digital or discrete (a bunch of steps, a policy, an algorithm) because that’s all we can do to try and reduce costs instead of investing more. Try and capture what the essence of what a human is trying to do, then given it to some other human who can do it cheaply (either in a different country or somoene cheaper in country). And then the logical conclusion of this trend is to completely remove the human from the equation and replace them with an AI, because that’s all we are focussing on now – the steps, and how we can save costs.

This is why the world just feels shitty nowadays, I think. There’s less and less of a human touch/ interaction. Even when you get to talk to a human on the other end of a customer support call or shop etc., they have less autonomy because they have a script they must follow. They can’t make decisions because that’s what they have been told. And if you push back, you are just told that that’s the policy.

And this feeling is what Madhumita manages to convey in Code Dependent, though maybe not so explicitly. (These ideas have been going around in my head for a bit coz of all the non-fiction reading I do, especially “Survival of the Richest” recently which had similar themes, so my overall feeling of the book was also coloured with this).

A good read, highly recommended!