I have seen way too many people rely on tracing (which brought back some 2008-ish PHP memories), so just thought I would summarize the whole process here.

First off, let’s start with docs. Tldr; you have to use the Plugin Registration Tool (PRT) (pac tool prt --update - make sure you have the latest version).

Next, build your plugin in Debug configuration (simple dotnet build does the job usually). This process works for both ILRepack and also for plugin packages.

If you are using ILRepack, ensure that you also get correct PDB file. I had to configure output to a different folder in order for proper PDB to be generated. Without correct PDB, you won’t be able to debug the code.

Before launching PRT, navigate to %LOCALAPPDATA%\Microsoft\PowerPlatform\PRT\9.1.0.200\tools (the version will change in time) and modify appsettings.json to have LegacyPluginProfiler set to false instead of true. This step is very important if you want to debug plugin packages, and I haven’t found any reason why not to have this enabled for any kind of debugging. After this, launch PRT (pac tool prt). This step is described in French docs (and few other languages) but not in any English version.

You have to disable the LegacyPluginProfile in order to be able to debug plugin packages, if you use the legacy one, you will get Unexpected Exception in the Plug-in Profiler error in the API and some more details in the trace log since plugin packages are stored differently than plugin DLLs.

Now import your plugin/package and create the steps and do all the usual stuff. Make sure that Plugin Trace Log is enabled (you can do this in PRT too).

Next you can simply follow the docs - Start Profiling (you won’t see the Profile Settings window if you configured PRT correctly). Perform an action to execute the plugin. Then you can just go to Debug, select the execution from the history, and then select the assembly.

Finally, you can just Attach to Process from Visual Studio and replay the execution. If you are using VS Code, create launch.json and set the following (note the type is set to clr instead of coreclr because you are debugging .NET Framework):

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Attach",
            "type": "clr",
            "request": "attach"
        }
    ]
}

Have fun debugging!

In the past I have done many Remote Desktop Service deployments, some of which are still running to date. The first requirement however is, I don’t want to host a Windows Server. Second, I don’t want to manage an Active Directory either (it is a requirement). Third, I preferably want to deploy this on my existing server and preferrably as a Docker container.

So I started searching around and found out that there are a few (not really well known) implementations of the Remote Desktop Gateway and its protocol:

• https://github.com/mKenfenheuer/rdpgw.net/ (C#, also has a working sample)
• https://github.com/bolkedebruin/rdpgw (Go)
• https://github.com/gabriel-sztejnworcel/pyrdgw (Python)

All of these libraries seem to implement it in a similar fashion, however I found the RDPGW in Go the most complete - it also ships as a Docker container, which you can just use - the only issue is that the documentation is somewhat not complete and some things are not really working - yet.

With this implementation, you can choose between openid, local (Basic authentication), ntlm, headers (when behind Cloudflare Access or Azure App Proxy) and kerberos. Initially I wanted to go with NTLM authentication, because you can easily configure it from each of the clients as gateway credentials, however I have hit two issues - Cloudflare doesn’t support proxying NTLM authentication (and I want it published through Cloudflare Tunnel) and NGINX doesn’t support NTLM either (only as part of commercial subscription, there is a free and OSS module but I haven’t tried it, since I want it behind Cloudflare anyways) - I use NGINX as an ingress proxy for all containers and services I host. The next choice was the basic authentication option - and while this would be pretty much suitable for me, it doesn’t work with native MSTSC client (documentation says that RDCMan works, but I didn’t manage to get it working either - RDCMan is just a GUI on top of MSTSC anyways), despites even explicitly setting gatewaycredentialssource to 3. Next, I configured it for header authentication, which is however crashing due to a little bug.

The last option was to go with OpenID Connect setup. This method worked across all platforms, and let me go a little bit into how it works: First, you have to visit https://rdgateway.domain.com/connect?host=xxx.corp.domain.com:3389 and authenticate, which in return will give you a .rdp file preauthenticated to the gateway. You then open the file in MSTSC or Windows (on MacOS or iOS) apps, and authenticate to the target computer. The authentication token to the gateway is shortlived, so in case you need to reconnect, you have to download the file again.

The authentication token is stored in gatewayaccesstoken property in the .rdp file itself (it is a shortlived - 5 minutes - JWT token), which the gateway verifies and let’s you connect. It is also refered to as the PAA Cookie. So thanks to this, you can easily connect to your machine from native client, from anywhere without the need for a VPN or running cloudflared.

The only disappointing thing is, that there’s no interactive way to continuously obtain the gatewayaccesstoken from an IdP in some modern way (so you could skip the entire download a RDP file thing).

I am currently looking into ways to either contribute to the RDGW in Go to fix some of the quirks with the header authentication or leveraging the C# implementation to make my own gateway server in the future.

I also have eyes on Azure Virtual Desktop hybrid deployment. It appears to be in private preview (and the form is already closed). It could remove the need for hosting the gateway completely, since the Arc-enabled machine could be acessibly from AVD directly. I hope to learn more about it soon.

There are already GUI tools to export the Audit table - some available through XrmToolbox but we want this to be done automatically in the background without having to do manual cleanup. And we can achieve this via export to Data Lake Storage in Azure. While there is already a guide for this it requires you to deploy Azure Synapse Workspace and an Apache Spark pool which will incur additional costs but you can do it without all of that.

First, you need to decide on what you plan to use those audit logs for - if you have them just as a backup, or access them in a very infrequent way, you can safely offload the audit elsewhere. You can offload everything and then for example keep 1 year of audit in Dataverse for easy access, and over that in Data Lake for long-term retention. Remember that once you offload the audit, it will be in the CSV format in the Data Lake, so you will need another tool (like Power BI or actual Azure Synapse Link) to search through the data easily. So let’s get it running:

First, create a Data Lake storage account in Azure, preferrably in the same region as your Dataverse and make sure to enable Hierarchical Namespace (you can follow this guide). Next, proceed with connecting the Data Lake to Dataverse, you can follow these steps, however you will notice, that there is no Auditing table available. That’s fine, just select some other table (preferrably some table which you are not using like adx_ads), save it, and wait for it to complete.

Next, open F12 Developer Tools and select the Network tab. With those tools open, navigate to the Data Lake configuration, and find the GET request going to the athenawebservice.*.gateway.prod.island.powerapps.com. From the GET request’s body and headers, you need to populate the code below:

const url = "<url>"; // https://athenawebservice.neu-il103.gateway.prod.island.powerapps.com/environment/2b780552-3247-473b-ba66-e3681799d66f/lakeprofile/39ee4c30-8487-48e6-b476-a55731f66171
const authorization = "<authorization_header_value>"; // Bearer ...
const id = "<id>"; // GUID
const name = "<name>"; // name
const organizationId = "<organization_id>"; // GUID
const organizationUrl = "<organization_url>"; // URL
const lakeId = "<lake_id>"; // GUID

await fetch(url, {
  "headers": {
    "accept": "*/*",
    "authorization": authorization,
    "cache-control": "no-cache",
    "content-type": "application/json",
  },
  "body": JSON.stringify({
    "Id": id,
    "Version": "1.0",
    "State": 1,
    "LastModified": "2023-11-20T22:10:17",
    "Name": name,
    "OrganizationId": organizationId,
    "OrganizationUrl": organizationUrl,
    "Entities": [
        {
            "Type": "audit",
            "EntitySource": "Dataverse",
            "AppendOnlyMode": false,
            "PartitionStrategy": "Month",
            "RecordCountPerBlock": 0,
            "Settings": {}
        }
    ],
    "DestinationType": 4,
    "DestinationKeyVaultUri": "dummy",
    "DestinationPrefix": "",
    "LakeId": lakeId,
    "RetryPolicy": {
        "MaxRetryCount": 12,
        "IntervalInSeconds": 5,
        "Backoff": 0
    },
    "Status": {
        "ExportStatus": "Success",
        "InitialSyncState": "Completed",
        "TotalNotifications": 0,
        "SuccessNotifications": 0,
        "FailureNotifications": 0,
        "LastExportDate": null,
        "LastModifiedOn": "2023-11-20T22:10:17",
        "MetadataState": "Created",
        "ForceRefreshState": "NotStarted",
        "LastForceRefreshRequestTime": null,
        "LastForceRefreshStartTime": null,
        "LastForceRefreshEndTime": null
    },
    "WriteDeleteLog": true,
    "CountFeature": false,
    "CreationTime": "2023-11-20T22:10:17",
    "ActivationTime": "2022-04-11T12:26:19",
    "UpdateTime": null,
    "DestinationSchemaName": "dbo",
    "NeedCopyAttachmentsToBlob": false,
    "NeedCopyFileTypeAttachmentsToBlob": false,
    "EnabledForJobs": true,
    "EnabledForIncrementalUpdate": false,
    "EnabledForDeltaLake": false,
    "EnabledForDlw": false,
    "IncrementalUpdateTimeInterval": 60,
    "SynapseSyncState": "NotStarted",
    "LinkedToFabric": false,
    "EnabledForFnOTablesBaseEnumSupport": false,
    "IsDeDuplicationJobsSubmitted": false,
    "LinkedFnOEnvironmentLastObservedValue": null,
    "ShouldSkipShortCutsDeletionInOLCFlow": false,
    "ProfilePauseResumeOperationsType": 8,
    "LinkedFnOEnvironmentCurrentAOSCount": 0,
    "LinkedFnOEnvironmentAdditionalAOSCount": 0
  }),
  "method": "PUT",
  "mode": "cors",
  "credentials": "include"
});

await fetch(`${url}/activate`, {
  "headers": {
    "accept": "*/*",
    "authorization": authorization,
    "cache-control": "no-cache",
    "content-type": "application/json",
  },
  "body": null,
  "method": "POST",
  "mode": "cors",
  "credentials": "include"
});

Once you do that, you can copy paste it to the console in the developer tools and execute. It will update the export profile and active it, and in a minute the audit log will begin to be exported into the Data Lake.

WARNING: Remember, you are executing a code from the Internet, so always make sure it is going to do what you expect it to do.

Once the intial export finishes, you can then configure the audit log retention to a lower time in Dataverse and also trigger the audit deletion if you want to delete older logs immediatelly (more on that in another article).

And you are all set, audit is now persisted in much cheaper storage. I am kind of surprised that exporting audit to Data Lake directly without Azure Synapse Link is not supported, but at least it works this way.

My scenario

I accidentally stumbled upon this “feature” yesterday, while I was trying to expose SSH browser rendering for my Raspberry.

Basically, I wanted to expose it under raspberry.ssh.hajekj.net, however I ended up with ERR_SSL_VERSION_OR_CIPHER_MISMATCH in your browser (or similar), meaning that Cloudflare doesn’t have the corresponding certificate.

I am aware that I could publish it under ssh-raspberry.hajekj.net or something, but I just like the 4th level subdomain format better.

Cloudflare for SaaS to the rescue!

I have been doing a lot of experiments with Cloudflare for SaaS as an alternative to Azure Front Door. Since I had it setup on my domain, I just thought, let’s try to add the 4th level domain there (since Cloudflare for SaaS creates its own certificates) and see what happens.

I simply added the domain to DNS (via Published application from Cloudflare Tunnel, but orange clouded DNS record will work too) and also added the domain to Cloudflare for SaaS (Dashboard > SSL/TLS > Custom Hostnames),

After less than a minute, a certificate was issued and the host is published with a 4th level domain secured by Cloudflare’s certificate withou ACM (I just hope nobody disables this on Cloudflare’s side).

Some people actually call this a 3rd level domain, so I am just mentioning it down here for visibility.

There are actually multiple solutions to this problem - we could go with on-premises data gateway (which would most-likely require running a web server at customer’s environment - and handling auth etc.), we could go with Azure Relay (but that requires calling it via HTTP from Power Automate, and it’s Service Bus behind the scenes anyways), so we decided to go with Service Bus.

Service Bus supports sessions which can be used for implementing a request and response pattern.

The implementation is really simple. Everything starts when a Power Automate gets triggered with some data payload (from frontend in our case). Next, we generate the session’s ID by using expression guid() - we persist it in a variable, because we will also need it later.

In Service Bus, we create two topics - request with on-premise subscriber and response with Power Automate subscriber (make sure to enable sessions).

Next we send the message to the queue/topic and fill Session Id with the ID generated earlier. We also provide the message’s payload and any other things we need. This will send the message.

You then have a simple listener created via CreateProcessor:

public async Task DoWork(CancellationToken stoppingToken)
{
    _serviceBusProcessor = _serviceBusClient.CreateProcessor("<topic>", "<subscription>", new ServiceBusProcessorOptions
    {
        AutoCompleteMessages = true,
        MaxConcurrentCalls = 1,
        MaxAutoLockRenewalDuration = TimeSpan.FromMinutes(1)
    });
    _serviceBusProcessor.ProcessMessageAsync += MessageHandler;
    _serviceBusProcessor.ProcessErrorAsync += ErrorHandler;

    await _serviceBusProcessor.StartProcessingAsync(stoppingToken);

    while (!stoppingToken.IsCancellationRequested)
    {
        await Task.Delay(10000, stoppingToken);
    }
}

And in the MessageHandler:

private async Task MessageHandler(ProcessMessageEventArgs args)
{
    var sessionId = args.Message.SessionId;
    var message = args.Message.Body.ToObjectFromJson<Message>();

    try
    {
        // ... do your processing
        await _serviceBusSender.SendMessageAsync(new ServiceBusMessage
        {
            SessionId = sessionId,
            ReplyToSessionId = sessionId,
            Body = BinaryData.FromObjectAsJson(new Message
            {
                // Your response data...
            }),
        });
        await args.CompleteMessageAsync(args.Message);
    }
    // You should do proper error handling...
    catch (Exception ex)
    {
        await args.DeadLetterMessageAsync(args.Message, ex.Message);
    }

}

Next in Power Automate, you will add a trigger into the flow’s body (yes, that’s right, you can use triggers mid-flow). In this case, we use When a message is received in a topic subscription (peek-lock) trigger. The important thing is to provide the Session id parameter, so the flow will get triggered only on the reply to the initial message. When you receive the message, make sure to complete the message since the trigger is only peek-lock (the auto-complete doesn’t support sessions).

This way, the flow pauses and just resumes running when a response arrives and thanks to it, you don’t need to manually store flow’s state and restore it.

If you are using HTTP Request trigger / Response action (or a connector based on these), remember the maximum execution time is 2 minutes, so if the execution time is longer, make sure to enable the asynchronous response pattern and properly consume it on the client.

Why would you want to use TDS in your plugin?

For example to perform advanced roll-up like operations - to calculate things in real-time or handle the calculation more efficiently - because FetchXML is limited compared to SQL.

For example, you can perform a query like this:

SELECT contact = (SELECT COUNT(lastname) as count FROM contact), account = (SELECT COUNT(name) as count FROM account)

Which will return a real-time count of the records (yes, even if it’s above 50,000), do multiple nested GROUP BY statements and much more.

Your options

Connecting directly via SQL

Probably the easiest option is to connect to the SQL directly from plugin which has been described here or here for example. The issue with the code here, is that you also need to create an app registration and the query will then be authorized by the service principal’s permissions, rather than the user’s, which potentially introduces security risks. And there is no way to retrieve user’s token in the plugin to perform proper impersonation.

Using ExecutePowerBISql request from within plugin

Previously “documented” by Mark Carrington (here and here), you can make use of the ExecutePowerBISql message which allows you to pass in SQL query and retrieve the response. This message can be executed only through the IOrganizationService interface (calling it via Xrm.WebApi.online.execute won’t work) and it can be called from within a plugin which wasn’t previously possible (we created our own proxy in Azure Functions to be able to call TDS from client/server/Power Automate).

So from within your plugin, you can call code like this:

var request = new OrganizationRequest("ExecutePowerBISql")
{
    Parameters = new ParameterCollection
    {
        ["QueryText"] = "select * from account"
        // ["NameMappingOptions"] = SqlNameMappingOptions.LogicalName  // Optional: https://learn.microsoft.com/en-us/dotnet/api/microsoft.xrm.sdk.sqlnamemappingoptions?view=dataverse-sdk-latest
        // ["QueryParameters"] =  new ParameterCollection // Optional: https://learn.microsoft.com/en-us/dotnet/api/microsoft.xrm.sdk.tdspowerbisqlrequest?view=dataverse-sdk-latest
        // {
        //     { "@parameter1", "Value1" },
        //     { "@parameter2", 123 },
        // }
    }
};
var response = localPluginContext.PluginUserService.Execute(request);
var dataset = (System.Data.DataSet)response.Results["Records"];
// ...

You don’t need to perform any other authentication or create an app registration because it will use the calling user for authorization automatically, so it is much more convenient.

This however only works in a synchronous plugin, if you set it to run as asynchronous, you will end up with a missing dependency exception:

System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: An unexpected error occurred. (Fault Detail is equal to Exception details: 
ErrorCode: 0x80040216
Message: An unexpected error occurred.
TimeStamp: 2025-11-05T08:02:47.0000000Z
OriginalException: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: An unexpected error occurred. (Fault Detail is equal to Exception details: 
ErrorCode: 0x80040216
Message: An unexpected error occurred.
TimeStamp: 2025-11-05T08:02:47.6476346Z
--
Exception details: 
ErrorCode: 0x80040216
Message: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.TransactSql.ScriptDom, Version=16.1.0.0, Culture=neutral, PublicKeyToken=[REDACTED] or one of its dependencies. The system cannot find the file specified.
at Microsoft.Crm.ObjectModel.PSqlService.GetSqlQueryEvaluationVisitor(String queryText, IExecutionContext executionContext, PSqlDatabaseContext pSqlDatabaseContext)
at Microsoft.Crm.ObjectModel.PSqlService.GetSqlExecutor(IExecutionContext executionContext, String queryText, PSqlDatabaseContext pSqlDatabaseContext...).

UPDATE (11NOV2025): You can also encounter this error if you are executing this on Retrieve for example, and the retrieve operation is triggered from an asynchronous context (for example Dataverse trigger’s filter in Power Automate), because it will cause the code to run in the asynchronous sandbox.

Calling from client

If you want to call this from the client (eg. client-script or PCF) the easiest option is to wrap the above into a Custom API. This will also allow you to call it from Power Automate.

Alternatively, you can call the organization service web proxy through JavaScript (ExecutePowerBISql is not available through OData endpoints unfortunately, so you have to use the SOAP call below):

async function executePowerBISql(queryText) {
    // You can provide additional parameters as shown above
    const soapEnvelope = `
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
      <s:Body>
        <Execute xmlns="http://schemas.microsoft.com/xrm/2011/Contracts/Services">
          <request i:type="a:OrganizationRequest" xmlns:a="http://schemas.microsoft.com/xrm/2011/Contracts" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
            <a:Parameters xmlns:b="http://schemas.datacontract.org/2004/07/System.Collections.Generic">
              <a:KeyValuePairOfstringanyType>
                <b:key>QueryText</b:key>
                <b:value i:type="c:string" xmlns:c="http://www.w3.org/2001/XMLSchema">${queryText}</b:value>
              </a:KeyValuePairOfstringanyType>
            </a:Parameters>
            <a:RequestName>ExecutePowerBISql</a:RequestName>
          </request>
        </Execute>
      </s:Body>
    </s:Envelope>`;

    const response = await fetch("/XRMServices/2011/Organization.svc/web", {
        method: "POST",
        headers: {
            "Content-Type": "text/xml; charset=utf-8",
            "SOAPAction": "http://schemas.microsoft.com/xrm/2011/Contracts/Services/IOrganizationService/Execute"
        },
        body: soapEnvelope
    });

    const responseText = await response.text();
    return responseText;
}

const result = executePowerBISql("select * from account");
// parse result...

Wrap up

You can see that calling TDS is possible from both client and plugin without any additional authentication requirements. While it’s probably not officially supported, it is quite a nice way to quickly perform advanced queries. I am not really happy that these things are not exposed to Power Platform developers because it just creates more complications when trying to do something a little more advanced (but it is what it is).

Before events were available, we utilized a library loaded on the form’s load event, and then executed it by finding the right iframe where the script lives and then executing the method passed in through parameters. In some cases, there are multiple “handlers” with specified order.

With events, obtaining a result through an async method becomes much more complicated, since you have to pass a custom method to call back with result parameters and wait for the callback to be executed. Something like this:

let outputParameter1: string;
let promiseResolve: () => void;
const promise = new Promise((resolve) => {
    promiseResolve = resolve;
});
// Wrap the rest into try {} catch (err) {}
context.events.customEvent1({
    parameter1: "<parameter_1>",
    parameter2: {
        parameter: 2
    },
    callback: (outputParam1: string) => {
        outputParameter1 = outputParam1;
        promiseResolve();
    }
});
// Use Promise.race to implement timeout and prevent hangs
await promise();
console.log(outputParameter1);

In the handler script, you would end up doing something like this:

namespace Your.Namespace {
    export class Class {
        static async OnLoad(executionContext) {
            const formContext = executionContext.getFormContext();
            const sampleControl1 = formContext.getControl("<control_name>");
            sampleControl1.addEventHandler("customEvent1", async (params) => {
                console.log(params.parameter1);
                const accounts = await Xrm.WebApi.retrieveMultiple("account", "?$top=1");
                params.callback(accounts[0]["name"]);
            });
        }
    }
}

You can see that the code above is quite complex, and becomes even more complex for proper error handling, timeouts to prevent hangs etc. I haven’t tested what happens when you have multiple event subscribers, but I believe that it would result in even more complex code.

Over time, I discovered a method called Xrm.Utility.executeFunction which is undocumented, but allows you to specify a web resource, method to call and parameters to pass. It also handles script’s dependencies, translations etc. As a result, you will get a Promise which you can await to get the result. And you don’t need to attach the script beforehand.

Calling it is super simple:

// Wrap this into try { } catch (err) { }
const result = await Xrm.Utility.executeFunction("webresource.js", "Your.Namespace.Class.Method", ["<parameter_1>", { parameter: 2 }]);

Handling the call and returning a result is also easy:

namespace Your.Namespace {
    export class Class {
        static async Method(parameter1: string, parameter2: object): Promise<string> {
            console.log(parameter1);
            const accounts = await Xrm.WebApi.retrieveMultiple("account", "?$top=1");
            return accounts[0]["name"];
        }
    }
}

The code above will execute the script, but there’s a catch. The limit for execution is 10 seconds, if the code runs longer, executeFunction will throw an error. So if you need to use this to collect some data from the user - for example via a dialog or have something long running, you will still need to resolve to a similar pattern with Promise and callbacks like with events.

Something like this for the caller (you can make a nice wrapper for this):

let outputParameter1: string;
let promiseResolve: () => void;
let promiseReject: (reason: any) => void;
const promise = new Promise<void>((resolve, reject) => {
    promiseResolve = resolve;
    promiseReject = reject;
});
const result = await Xrm.Utility.executeFunction("webresource.js", "Your.Namespace.Class.Method", [
    "<parameter_1>",
    { parameter: 2 },
    (outputParam1: string) => {
        outputParameter1 = outputParam1;
        promiseResolve();
    },
    (error: any) => {
        promiseReject(error);
    }
]);
try {
    await promise();
    console.log(outputParameter1);
} catch (error) {
    console.error(error);
}

And this for the handler:

namespace Your.Namespace {
    export class Class {
        static async Method(parameter1: string, parameter2: object, callback: (outputParam1: string) => void, reject: (error: any) => void): Promise<boolean> {
            (async () => {
                try {
                    console.log(parameter1);
                    const accounts = await Xrm.WebApi.retrieveMultiple("account", "?$top=1");
                    callback(accounts[0]["name"]);
                } catch (error) {
                    reject(error);
                }
            })();
 
            return true;
        }
    }
}

This results in much cleaner and more readable code than using the wrappers for events. Have fun!

Remember that you can however only use Xrm.* methods in model-driven apps only, and it won’t work in canvas or Power Pages.

Using esbuild to build PCF is however undocumented besides the release notes saying it’s an experimental feature and that it has to be enabled via featureconfig.json file (we will explore some other options in another article).

So when you create featureconfig.json file and add the following flag into it:

{
    "pcfUseESBuild": "on"
}

You will also need to add a peer dependency called esbuild into your control. Simply do it by npm i esbuild or whatever you use as your package manager.

Once you set this up, you can now call npm run build. Hopefully your control will build without any issues (I haven’t hit any issues in our ~60 control repo - React, Fluent and bunch of other libraries used). Also remember that if it builds, it doesn’t mean it will work, so test it thoroughly.

The build will output bundle.js, you can even pack it into a solution, but if you run the control (via harness or in Power Apps), it will not run. The issue here is that this feature is either unfinished (yes, it’s experimental, but …) and probably lacks documentation, or more work needs to be done.

The control is missing registration with Power Apps host (or test harness host). This is a few lines of code which is added by a build step of webpack and looks like this:

if (window.ComponentFramework && window.ComponentFramework.registerControl) {
    ComponentFramework.registerControl('TALXIS.PCF.CompanyProfileHinting', pcf_tools_652ac3f36e1e4bca82eb3c1dc44e6fad.CompanyProfileHinting);
} else {
    var TALXIS = TALXIS || {};
    TALXIS.PCF = TALXIS.PCF || {};
    TALXIS.PCF.CompanyProfileHinting = pcf_tools_652ac3f36e1e4bca82eb3c1dc44e6fad.CompanyProfileHinting;
    pcf_tools_652ac3f36e1e4bca82eb3c1dc44e6fad = undefined;
}

The most important part here is ComponentFramework.registerControl call, I haven’t found the use for the rest. So simply to end of your index.ts file, add the following:

// @ts-ignore
if (window.ComponentFramework && window.ComponentFramework.registerControl) {
    // @ts-ignore
    ComponentFramework.registerControl('Your.Full.Namespace.Control', Control);
} else {
    throw new Error("ComponentFramework.registerControl is not present!");
}

Now try to build your control and run it either in Power Apps or control harness. It is going to build way faster than with webpack, and we’re talking tens of seconds saved with some large controls!

Are there any downsides to this? Yes. It is experimental, which means that it is not likely supported by Microsoft. It is undocumented and unfinished. It may change over time. It also doesn’t support any customization like webpack (custom webpack config, platform libraries and more), but in our setup, we can do just fine without it. Also note, that esbuild is still in development and hasn’t hit 1.0 stable version at the time of writing.

I am really looking forward to see where Microsoft takes this (and I hope they allow some extensibility and add feature parity with webpack).

GitHub Enterprise pricing

NETWORG is a Microsoft Partner and we get some of our licenses from Microsoft Partner program (Visual Studio Enterprise in this matter). Visual Studio Enterprise grants the user full access to Azure DevOps, but doesn’t grant any benefits in regards to GitHub (yes, there is some separate SKU, but you don’t get that). Additionally, a seat in Azure DevOps costs $6 per month per user, while with GitHub Enterprise, it is $21.

I don’t want to speculate on the topic “GitHub vs Azure DevOps and the future” so I will leave it out on purpose.

Why on earth do you need GitHub Enterprise when doing OSS?

Security and identity management. We streamlined our IAM into Entra ID. May it be for SSO enabled apps, Bitwarden or other apps. I want to have a single place to manage access, and especially onboarding and offboarding users.

Besides, we use GitHub for Open Source projects, our customer project are still in Azure DevOps, and things are going to stay that way.

I am aware there is GitLab, and other solutions where you can setup SSO for free, but it’s not as convenient as using GitHub of course.

You want security, you have to pay more!

This is not just limited to GitHub Enterprise, there are many software vendors who include SSO only in their Enterprise plans - which are literally unaffordable for small businesses. May it be Twilio, Cloudflare and many others.

One of the things I am really having a hard time wrapping my head around - everybody is boasting about how secure their platforms are, yet, making every user own another account (and setting additional credentials) and adding administrative overhead (for onboarding and offboarding) probably doesn’t count, because in the end of the day, it’s on the shoulders of their customer, eg. us for example.

And I am not the only one having issue with this. There is even a site called SSO.TAX where they keep a list of vendors doing this practice.

I am well aware that things cost money, but I don’t want to pay for 50 other features which I will not use just to get SSO.

Our approach and solution

Since we won’t have SSO with GitHub without getting Enterprise, and the costs for that are not really justifiable for doing just OSS and giving some bits back to the community, we decided to at least handle user provisioning and deprovisioning and team membership based on Entra information. This is where NETWORG/github-organization-management comes in.

GitHub Organization Management

We decided to utilize GitHub’s rich APIs for organization management to handle invites, removals and team memberships and synchronize it with Entra ID. This is not a first of its kind project - Microsoft already made and opensourced something similar - their Open Source Management Portal. However their solution is a little bit overkill for our use - it handles roles, repo management, compliance and much - many of the things you don’t need when you are a small business.

Focusing on the basics we needed, it features the following:

• Invite users to GitHub organizations
• Remove disabled/deleted/out-of-scope users from GitHub organizations
• Maintain team memberships based on Entra ID group memberships
• Supports B2B guest accounts and their membership in groups
• Doesn’t require GitHub Enterprise
• Doesn’t interfere with external collaborators
• Doesn’t interfere with direct assignments and teams not linked to Entra ID groups
• Supports multiple organizations against a single Entra ID tenant
• Exempt users (e.g. service accounts, admins) from organization removal (in case things go wrong)

Through a simple user interface, users are required to link their Entra ID account with their GitHub account by signing in to both (GitHub account ID is persisted as a directory schema extension in Microsoft Graph), and then, based on the groups the person is member of, the access is calculated and applied - user is invited, and upon accepting invitation added and synchronized into GitHub Teams linked with Entra ID groups. When the account is disabled or deleted in Entra, the user will be removed from the organization (or when they lose access to the teams giving them the entitlement). GitHub Teams are linked based on an Entra Group ID provided in the team’s description field, eg. Entra: <group_id>.

This works perfectly fine with Entitlement Management in Entra to manage memberships, even some basic Just-In-Time (JIT) access can be built thanks to this.

The user still has to use their regular GitHub account, but we enforce use of 2FA at organization level which in combination with the above is good enough.

Currently, you have to manually trigger the sync process via an HTTP endpoint, but this will be soon moved to a worker. We are currently running this project in Azure Container Apps.

The project is open source and currently is still work in progress, but I just wanted to share the progress. You can follow it or even contribute to it on GitHub.

Distribution groups are somewhat a special object in Microsoft Graph. You can read them, but you can’t manipulate them (eg. add/remove members, rename etc.). This is because they are “Exchange mastered”, meaning that the group’s master data is stored in Exchange and only some part of it is replicated to Microsoft Graph, but there’s no functionality to replicate it back (despites Exchange support for dual-write). I will not discuss whether you should be still using them or switching to M365 groups in this article.

So using Fiddler and executing New-DistributionGroup, I discovered that the Exchange Online PowerShell calls the following REST API endpoint: https://outlook.office365.com/adminapi/beta/<tenantId>/InvokeCommand with the documented parameters. This allows them to execute any of the EXO PowerShell commands and the API acts just like a PowerShell proxy.

So now I had to figure out authentication. I want to use the client_credentials flow, since in my case the service is operating by a daemon, however you can use delegated permissions in case the user is interacting with your app or Managed Identity if you are running in Azure (or Azure Arc). We start by creating a standard app registration (either single or multi-tenant) or you can make use of managed identity. Then you need to go to API Permissions and add Office 365 Exchange Online app with application scope Exchange.ManageAsApp or simply add the following to your manifest’s requiredResourceAccess:

{
    "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
    "resourceAccess": [
        {
            "id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
            "type": "Role"
        }
    ]
}

And then you need to give the application a role to manage Exchange. I assigned the application Exchange Recipient Administrator role.

The original setup was that we had a PowerShell Azure Function which used the ExchangeOnlineManagement module and executed the command, so the code below will be in PowerShell, but you can easily transform it to any language of your choice since those are just REST calls (or ask Copilot).

$clientId     = "<client_id>"
$clientSecret = $env:EXO_CLIENT_SECRET # Your client_secret - retrieve it from ENV or Key Vault or somewhere
$tenantId     = "<tenant>.onmicrosoft.com"

$tokenBody = @{
    client_id     = $clientId
    client_secret = $clientSecret
    scope         = "https://outlook.office365.com/.default"
    grant_type    = "client_credentials"
}

try {
    $tokenResponse = Invoke-RestMethod -Method Post -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Body $tokenBody -ContentType "application/x-www-form-urlencoded"
    $accessToken = $tokenResponse.access_token
}
catch {
    # Handle token retrieval failure (this code applies to Azure Function)
    Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
        StatusCode = [HttpStatusCode]::Unauthorized
        Body = "Failed to acquire token: $($_.Exception.Message)"
    })
    return
}

So with this token, you can then execute the InvokeCommand endpoint as follows:

$groupOwner = "<alias>@<domain>"
$groupName = "<displayName>"
$emailAddress = "<alias>@<domain>"
$members = @("<alias1>@<domain>", "<alias2>@<domain>")
$anchorUpn = "<alias>@<domain>" # This should be a mailbox in the same GEO as the DG you are targeting (for single geo, just use admin user's UPN)

$payload = @{
    CmdletInput = @{
        CmdletName = "New-DistributionGroup"
        Parameters = @{
            RequireSenderAuthenticationEnabled = $false
            MemberJoinRestriction              = "Closed"
            Members                            = $members
            ManagedBy                          = $groupOwner
            ErrorAction                        = "Stop"
            MemberDepartRestriction            = "Closed"
            Name                               = $displayName
            PrimarySmtpAddress                 = $emailAddress
            DisplayName                        = $displayName
        }
    }
} | ConvertTo-Json -Depth 10

$headers = @{
    "Authorization"       = "Bearer $accessToken"
    "X-CmdletName"        = "New-DistributionGroup"
    "X-ResponseFormat"    = "json" # ExchangeOnlineManagement sends `clixml` but you can use `json` to have less hassle with the output
    "X-ClientApplication" = "ExoManagementModule"
    "X-AnchorMailbox"     = $anchorUpn
    "Content-Type"        = "application/json"
    "Accept"              = "application/json"
}

try {
    $webRequest = Invoke-WebRequest -Uri "https://outlook.office365.com/adminapi/beta/$tenantId/InvokeCommand" -Method POST -Headers $headers -Body $payload -ContentType 'application/json' -UseBasicParsing
    $responseJson = $webRequest.Content | ConvertFrom-Json

    # Success, return the command response to the caller as JSON
    Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
        StatusCode = [HttpStatusCode]::OK
        Body = $responseJson.value[0]
    })
    return
}
catch {
    # Handle the exception
}

This way, you can execute any supported command against EXO without the need of PowerShell and you can call it from Power Automate for example via HTTP actions.

Is this supported? I would say yes and no. Cince the ExchangeOnlineManagement module makes use of it (and the module itself IS supported), it shouldn’t matter whether you call these endpoints via the PowerShell module or via REST (since that’s what the module does anyways). If it breaks, just open Fiddler and adjust the commands accordingly (or use it in case you can’t figure out the correct parameters).