AuditEDMS · Setup

Two scripts connect AuditEDMS to your Microsoft 365.

AuditEDMS runs in your own Azure subscription and signs your staff in with your own Microsoft Entra ID. A deployment template cannot register an application in your directory, or give anything access to SharePoint or a mailbox; only your own administrators can. These two scripts are how they do it: one before you deploy, one after. Read them before you run them. Both are safe to run again, and both take -WhatIf.

At a glance

	Before you deploy	After you deploy
Script	`New-AuditEdmsAppRegistration.ps1`	`Grant-AuditEdmsMicrosoft365Access.ps1`
Purpose	Staff sign-in	SharePoint filing, notifications, email intake
Who runs it	Anyone allowed to register applications	Your Microsoft 365 administrators
Where	Azure Cloud Shell, PowerShell	Azure Cloud Shell, PowerShell
Takes	About a minute	About five minutes
Needed to use AuditEDMS at all	Yes	No. Until it is run, documents are kept in your deployment's own storage and notifications wait

Downloads

Each release of AuditEDMS carries its own copy of the scripts. Use the release your deployment installed; the deployment's outputs name it.

Release	Script	SHA-256	Size
0.2.1	`New-AuditEdmsAppRegistration.ps1`	`e4dfd601e68fed8a89d7fa6dcd9c8f3028ca1b16d25ad0b071ce39de926d81e2`	32,164 bytes
0.2.1	`Grant-AuditEdmsMicrosoft365Access.ps1`	`a7d469c7faa2e4be8f311c171ab62096f32566153a79c9e328af493f1fed80d4`	83,889 bytes

In Cloud Shell:

PowerShell

$release = 'https://stauditedmsreleases.blob.core.windows.net/releases/<version>'
Invoke-WebRequest -Uri "$release/setup/New-AuditEdmsAppRegistration.ps1" -OutFile ./New-AuditEdmsAppRegistration.ps1
Invoke-WebRequest -Uri "$release/setup/Grant-AuditEdmsMicrosoft365Access.ps1" -OutFile ./Grant-AuditEdmsMicrosoft365Access.ps1
Get-FileHash ./*.ps1 -Algorithm SHA256

Compare each hash with the table. If one differs, do not run the file; write to support@creodata.com.

Before you deploy: sign-in

PowerShell

./New-AuditEdmsAppRegistration.ps1 -PortalUrl https://<portal address>.azurewebsites.net

Use the portal address you will type into the deployment wizard. The script prints three values for the wizard's Sign-in step: the tenant ID, the API client ID and the portal client ID.

What it creates. Two app registrations in your directory, "AuditEDMS API" and "AuditEDMS Portal", and a service principal for each. The API exposes one permission, to act as the signed-in user. The portal is a single-page application whose only redirect address is your portal, and it is approved in advance for that one permission, so your staff are not asked to consent.

What it does not create. No application permission, no secret and no certificate. Nothing it creates can read anything by itself.

If	Then
Your tenant does not let users register applications	Someone with the Application Developer role runs it
It stops when creating a service principal	An Application Administrator runs it again; it carries on from where it stopped
Your tenant has switched user consent off	A Cloud Application Administrator, Application Administrator or Privileged Role Administrator runs it with `-GrantAdminConsent`
You run it twice	The second run finds both registrations and changes nothing. Run with another address, it adds that address

After you deploy: SharePoint and mail

1
Create the SharePoint site. In the SharePoint admin centre: Sites, Active sites, Create, then a team site or a communication site. Name it for AuditEDMS, make the person who will run the script an owner, and keep external sharing to people in your organisation. The script does not create the site; it does create the five document libraries inside it.
2
Take the two identity values from the deployment. In the Azure portal, open the managed application, then Parameters and Outputs. The output microsoft365SetupCommand is the command below with both values filled in.

Run the script, in the tenant of the Azure subscription you deployed into:

PowerShell

./Grant-AuditEdmsMicrosoft365Access.ps1 -ApiPrincipalId <value> -IntakePrincipalId <value> -SiteUrl https://<tenant>.sharepoint.com/sites/<site> -SenderMailbox notifications@<your domain> -IntakeMailbox documents@<your domain> -CreateMailboxes

4
Paste what it prints into AuditEDMS, under Administration, Settings, Microsoft 365: the SharePoint site ID, the sender mailbox and the intake mailbox. Then choose Test connection. It checks each part and sends you one message from the sender mailbox.
5
Move earlier documents. If documents were filed before this step, the same screen offers to move them into SharePoint.

Signing in. In Cloud Shell the script signs in with a code: it shows a short code and the address of a Microsoft page to enter it on. You have two minutes for each. Microsoft Graph may ask twice in a row the first time, and Exchange Online asks once. The Graph sign-in shows Microsoft's consent screen for "Microsoft Graph Command Line Tools", Microsoft's own administration tool; accept it for yourself, without ticking consent on behalf of your organisation.

What each part of AuditEDMS ends up with.

	In Microsoft Entra ID	In SharePoint	In Exchange Online
The API	`Sites.Selected`, which by itself reaches no site	Write access to the one site you named	Send as the one sender mailbox
The Intake app	`Sites.Selected`	Write access to the same site	Read and file mail in the one intake mailbox

Neither can open any other site or any other mailbox, and the script finishes by proving it: it asks Exchange whether each identity can reach the other's mailbox and reports that it cannot. No mail permission is granted in Microsoft Entra ID, where it would reach every mailbox in your organisation.

What the script needs from the person running it.

Part	Role
`Sites.Selected` for the two identities	Privileged Role Administrator or Global Administrator
Access to the site	SharePoint Administrator
The libraries and their columns	An owner of the site
Mailboxes, mail access and mail flow rules	Exchange Administrator

Two administrators can share the work: run it once with -SkipExchange and once with -SkipSharePoint.

What stays yours to do. Block sign-in on the two shared mailboxes, as Microsoft advises for every shared mailbox. The script creates the mail flow rule that copies client mail to the intake mailbox switched off; you switch it on when you start using email intake.

Undo

Run the same command with -Remove added, after a look with -WhatIf. It takes away everything the script granted: the access to the site, Sites.Selected, the Exchange access and the mail flow rules. It deletes no data: the site, its libraries and the mailboxes stay. It ends by listing what it removed and what it kept.

To remove sign-in, delete the two app registrations in Microsoft Entra ID.

If something goes wrong

What you see	Why, and what to do
AADSTS50011, the redirect address does not match	The address given to the first script differs from the one typed into the wizard. Run the first script again with the right address
"Need admin approval" at first sign-in	User consent is switched off in your tenant. An administrator runs the first script with `-GrantAdminConsent`
The second script cannot find the identities	It is signed in to a different tenant from the Azure subscription. AuditEDMS reaches Microsoft 365 as the deployment's own identities, which live in the subscription's tenant
The sign-in code is not accepted	The two minutes passed. Run the script again; it carries on from where it stopped
The script stops with "A server side error has occurred"	Exchange Online had a passing fault. Run the script again, with `-Remove` if that is what you were running; it reports what is already done and does the rest
Documents are in Azure storage, not SharePoint	The second script has not been run, or the site ID has not been saved in Administration, Settings. Test connection says which
Test connection reports the sender as not allowed	Exchange can take up to two hours to honour new access. Test again later

Help

support@creodata.com, with the subject "AuditEDMS setup". Say which release you deployed and paste what the script printed; it prints no secrets.