DEV Community: Der Sascha

Stop logging PII: a configurable Node.js sanitizer logger

Der Sascha — Sun, 12 Jul 2026 05:02:45 +0000

Originally published on my blog: https://blog.bajonczak.com/stop-logging-pii-a-configurable-node-js-sanitizer-logger/

Logging is one of those topics that looks harmless until it is not.

A developer adds a request object to a debug statement. A payment error includes a card number. A support workflow logs an email address, a phone number, and a bearer token because "we only need it for troubleshooting." Two months later those logs are in a SIEM, a data lake, three alert rules, and a backup nobody remembers.

That is the part that bothers me about PII in logs: the first mistake is small, but the copies multiply quietly.

So I built a small Node.js example that sanitizes data at the logging boundary:

github.com/SBajonczak/PiiSanitizer

The idea is simple: before anything leaves your application as a log line, it passes through a configurable sanitizer. Common PII gets masked. Known sensitive object keys get redacted. Domain-specific identifiers can be configured without changing the logger code.

What the logger does

The repository currently provides a lightweight Node.js module with no runtime dependencies.

It can:

mask email addresses, phone numbers, IBAN-like values, and credit card numbers
redact sensitive keys such as password, token, authorization, and apiKey
walk nested objects and arrays without mutating the original input
emit either object records or JSON lines
accept custom rules for application-specific identifiers

The important design choice is that configuration owns the sensitive patterns. The logger should not need a new release every time a project discovers a new internal ID format.

Basic usage

Here is the smallest useful example:

import { createPiiLogger } from './src/index.js';

const logger = createPiiLogger({ format: 'json' });

logger.info('Login for jane.doe@example.com', {
  password: 'correct-horse-battery-staple',
  phone: '+49 170 1234567',
});

The output is safe to ship to container logs:

{
  "level": "info",
  "timestamp": "2026-05-14T12:51:45.760Z",
  "args": [
    "Login for [EMAIL]",
    {
      "password": "[REDACTED]",
      "phone": "[PHONE]"
    }
  ]
}

This is deliberately boring. Good logging infrastructure should be boring. The exciting part is everything that does not leak.

Configuring domain-specific rules

Every company has identifiers that do not look sensitive to a generic library.

In SAP-heavy landscapes, for example, a personnel number may show up as PERNR 12345678. Depending on the context, that can absolutely be personal data. A generic email masker will not catch it.

So the sanitizer supports custom regex rules and key rules:

import { createPiiLogger, defaultRules } from './src/index.js';

const logger = createPiiLogger({
  format: 'json',
  rules: [
    ...defaultRules,
    {
      name: 'sapPersonnelNumber',
      type: 'regex',
      pattern: '\\bPERNR[ -]?\\d{8}\\b',
      replacement: '[SAP_PERSONNEL_NUMBER]',
    },
    {
      name: 'employeeIdKey',
      type: 'key',
      keys: ['employeeId', 'pernr'],
      replacement: '[EMPLOYEE_ID]',
    },
  ],
});

logger.info('User jane.doe@example.com opened PERNR 12345678', {
  employeeId: '12345678',
  authorization: 'Bearer never-log-this',
});

Output:

{
  "level": "info",
  "args": [
    "User [EMAIL] opened [SAP_PERSONNEL_NUMBER]",
    {
      "employeeId": "[EMPLOYEE_ID]",
      "authorization": "[REDACTED]"
    }
  ]
}

The key rule is intentionally separate from the regex rule. Sometimes the value itself is harmless without context, but the field name makes it sensitive. A number called employeeId should be treated differently from the same number inside items[0].quantity.

Why sanitize at the logger boundary?

You can try to make every developer remember what not to log.

I would not bet a privacy incident on that.

The safer pattern is a boundary:

application code
  -> logger
  -> sanitizer
  -> stdout / log collector / SIEM

Application code can still make mistakes. The sanitizer catches the common ones before they leave the process.

This does not remove the need for good logging discipline. I still would not log raw HTTP requests, raw SAP payloads, payroll data, banking data, or identity documents. But a logger-level sanitizer gives you a last line of defense against accidental leakage.

A few implementation details

The sanitizer walks values recursively:

const output = sanitize({
  user: {
    name: 'Jane Doe',
    email: 'jane.doe@example.com',
    password: 'secret',
    profile: {
      phone: '+49 170 1234567',
    },
  },
});

Result:

{
  user: {
    name: 'Jane Doe',
    email: '[EMAIL]',
    password: '[REDACTED]',
    profile: {
      phone: '[PHONE]',
    },
  },
}

The original object is not mutated. That matters because logging should not change application state.

Credit card masking uses a Luhn check, so the sanitizer does not replace every long number it sees. That reduces false positives in boring business data, which is important if people are expected to keep this enabled.

Key matching ignores case, spaces, underscores, and dashes. These should all match the same rule:

accessToken
access_token
Access Token
access-token

Tests first, because this kind of code needs trust

I built the example test-first with Node's built-in test runner. No Jest, no Vitest, no dependency tree just to prove the point.

Run it with:

npm test

The tests cover:

masking common PII in strings
recursive object sanitization
custom SAP-style identifier rules
logger output through a custom sink
JSON-line logging for container environments

You can also run the example directly:

npm run example

What this is not

This is not a magic GDPR shield.

It does not decide whether you are allowed to process data. It does not classify every possible personal attribute. It does not replace data minimization, retention policies, access control, or a proper DPIA when one is needed.

It is a practical guardrail for a common failure mode: sensitive values accidentally ending up in logs.

And honestly, that is already useful.

Where I would take it next

The current repository is a small working foundation. The next useful steps would be:

package it properly for npm
add TypeScript type definitions
add adapters for popular loggers like Pino and Winston
add rule presets for common enterprise domains
add structured audit metadata so teams can see which rules fired
add benchmarks before anyone puts it on a hot path

But the core idea will stay the same: log what helps you operate the system, not whatever happened to be nearby in memory.

Source code: github.com/SBajonczak/PiiSanitizer

How to Logout from Azure B2C on all Services correctly

Der Sascha — Fri, 10 Jul 2026 13:59:45 +0000

Originally published on my blog: https://blog.bajonczak.com/how-to-logout-from-azure-b2c-on-all-services-correctly/

Azure B2C is an enterprise-scale B2C System. It comes with different tiers and also a free tier, so that will be interesting for every developer that wants authentication support with Facebook, Google, Amazon, or other Identity providers (IDP).

Most developers will generate a Login Flow and get the Token. When he wants to log out, he must only clear the cookie that will be created and remove the session from the browser cache. Then the current user is logged out. This scenario is a common scenario for many applications. Still, a few enterprise applications will act as a single point of entry and will then "redirect" to other services in your architecture.

The solution above (delete the cookie and remove the session) will not work.

The problem in multiapplication architecture

Let's assume you have an application as a "portal" that will redirect to some other services. This service will support single sign-on (SSO) through our application.

So now the user (User A) will get logged in, navigate through your other service, and will be signed in automatically. After a while, the user will go to your portal application again and sign out. Next on the same machine, a colleague (User B) will log on to the portal. After this, he will navigate to the service again and then you will recognize that User A was signed in instead of User B.

What happened here?

In your portal, you have removed only your authentication information from your portal. But the other service generated a separate cookie too. This cookie was not deleted by your code, so the service will keep the first logged-in user. Only when you actively sign off from the target system, you will get logged off.

"What? I must go through each portal to sign off?" you will ask now?

Technically yes, because every system does its own logout routine. So it will be better to call this sign-off function.

Azure B2C Solution 1

Instead of navigating through each logout URL of each service, Azure B2C hosts a single endpoint for this logout routine. Microsoft has a documentation page about this Url. So in simple, you must navigate through this URL

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2

What Azure B2C then will do is create on the Azure B2C Logoutpage a hidden Iframe. In this, it will navigate through each registered application and will call the defined logout URL. Once it is done, it will redirect you to the URL given by the parameter post_logout_redirect_uri.

Azure B2C Solution 2

Instead of waiting for the redirect and so on, you can do it asynchronously by calling a graph API method to revoke all login sessions for the current (or a specific) user.

When you want to logout by yourself and revoke your own session, you will be able to call only

https://graph.microsoft.com/beta/me/invalidateAllRefreshTokens

Please pay attention to delivering an actual OAuth token in the Authorization header for the current user. After the call is successful you will get an HTTP 204 back. That means that your call was successful.

The Graph API will give you also the possibility to log out a specific user by modifying the URL like this

https://graph.microsoft.com/beta/users/{id | userPrincipalName}/invalidateAllRefreshTokens

Instead of "Me" you will set the internal known user id to identify which session to revoke.

Conclusion

Yes Single Sign On works very well, it is quickly configured and it works then. But when you work with multiple applications you will get faced with a logout problem. This problem will prevent Azure B2C nice and smooth with the logout process. But when you want full control of the user sessions, you will be able to do this via the Office Graph API.

Implementing a captive portal for your ESP device

Der Sascha — Fri, 10 Jul 2026 13:59:39 +0000

Originally published on my blog: https://blog.bajonczak.com/implementing-a-captive-portal-for-your-esp-device/

Let's consider you are in a cafè and you want to go to the internet. You recognize that you can use the free wifi, so you select the wifi and a nice looking page comes up and prompt you for some information like email phone number and so on. This Portal is called a captive portal.

In one of my famous side project the Hivescale for my bees I use this captive portal to configure some specific for a tare or the first configuration like ... yes wifi connection and so on. This app is running on a small esp device and this will get some telemetry for my hives. So let me introduce you to how you can create a simple captive portal for your requirements.

Required libraries

Now that the meaning and application of a Captive Portal are clear, now let's do the practical way. I will guide you through a piece of code that you can adapt to your needs. First of all, we need a webserver that will host our website to represent the portal itself. I use for this the ESPAsyncWebserver library.

Please note the complete code can be found here: Captive Portal (github.com)

First we must include the libraries that we need to run

Next, we need some variables:

The AsyncWebServer is defined on port 80, which is the HTTP port.

Next, we literally define the HTML file as a raw string literal in the Program Memory called PROGMEM). It contains a form essentially, which asks the user for a name and ESP32 Proficiency:

Next, we create a CaptiveRequestHandler class which is inherited from the AsyncWebHandler class. Within the class, we have the two functions: canHandle() and handleRequest().

The canHandle() method simply returns true here, meaning that our captive portal can handle any request.

Next, the handleRequest function tells the AsyncWebServer what to do when a request is received. This is the function that is responsible for the captive portal opening up every time you connect to the WiFi of ESP32. We simply return the index_html page that we defined above (in our PROGMEM). Please note that send_P is used instead of send because we are fetching a large web page from the Program memory (PROGMEM).

The next function is very important. We set up theAsyncWebServer to respond to various requests, process the data received in the request and send a reply:

What we doing is to tell the server that when there is a GET request for the ‘/’ path, then redirect the user to index_html, and it receives a GET request for the ‘/get’ path (this will be at the time of form submission), then look for the name and proficiency in the response, and extract and store those fields is available, and send an acknowledgment to the user.

Note that “name” and “proficiency” are the names given to the input fields in index_html.

Also, note that the above function tells the server how to handle requests irrespective of the Captive Portal. In other words, if you connect to the ESP32’s WiFi field and enter the IP address in the browser, you’ll still be served by the index_html page, and if you fill out the form, your request will still be processed.

Next, in the setup() function, we initialize Serial, set the WiFi mode to Access Point (this helps create the WiFi field around ESP32), and name the WiFi field “my-captive”.

Then we set up the AsyncWebServer using the setupServer command. The next part is important. We set up and start the DNS server with the following line:

dnsServer.start(53, “*”, WiFi.softAPIP());

What does this mean? For that, we first have to understand the meaning of a DNS server. DNS stands for ‘Domain Name System’. When you type www.google.com in your web browser, the request gets sent to a DNS Server first, which translates this domain name into an IP Address, and then redirects the user to the corresponding IP address. On ESP32 we are creating our own DNS Server, and redirecting any domain name (*) to the IP of ESP32 (WiFi.softAPIP()). 53 stands for the port number. Just like HTTP requests are executed over port 80, HTTPS over port 443, DNS requests are executed over port 53.

So, what happens exactly? How does the system work? Every time your device connects to a new network, it tried to access a specific URL.

Which URL? That depends on your device. If it gets a response, it concludes that the internet is connected, else you see a message like “This WiFi has no access to the internet”.Now, when the device tries to connect with the ESP32’s WiFi, it again tries to send a request to a specific URL. The ESP32’s DNS server redirects it to the Soft AP IP address of ESP32, because remember, we are redirecting all domain names to this IP. On this IP, the captive request handler takes care of displaying the webpage, and the Async Web Server (set up using setupServer()), handles all the incoming request.

Of course, the next line is important, and last piece of the jigsaw puzzle. It links the Async Web Server with the Captive Request Handler, only when the request is in the Access Point mode.

server.addHandler(new CaptiveRequestHandler()).setFilter(ON_AP_FILTER);//only when requested from AP With the system ready, we begin the server.

Within the loop, we just keep processing the requests made to the dnsServer and, if name and proficiency are received, we print them.

Results:

Once you upload this code on the ESP32, the screenshots below will illustrate how the Captive Portal Works, and also the series of prints on the Serial Monitor.

Connecting to ESP32’s Wi-Fi field using a mobile phone

I hope you had fun creating the captive portal using ESP32!

Extending my IoT Doorbell with Alexa features

Der Sascha — Fri, 10 Jul 2026 13:59:33 +0000

Originally published on my blog: https://blog.bajonczak.com/extending-my-iot-doorbell-with-alexa-features/

In my post about how I got my doorbell smart, I thought... yes How can I extend it for now with some handy features?

So, in fact, the bell is loud, but what is it when I am in my garden and my door is closed and the delivery guy must hold a heavy package and try to ring the doorbell I do not open it because I didn't hear the bell. That's frustrating for everyone and may end up like this

via GIPHY

So I must be get noticed when the doorbell rings, for this I can use one of my Alexas, especially the Alexa dot. In my Garden, there is one for playing music while I work in the garden.

Thankfully I got Homeassistant as support for my Homeserver and it's controlling my House to automatically the most daily routines. So why not the notification for the doorbell?

What is Homeassistant

For those that don't hear anything about Homeassistant let me introduce this to you.

Homeassistant is a nice and handy tool that will allow you to control absolutely everything in your home (not only there). It integrates with most provided devices and custom ones (like ESP easy and so on).

On Top, there it comes with a nice handy web frontend that will allow you to create nice fancy (mobile-friendly) dashboards.

On the other site, you can create your custom automation, depending on actors like wall switches or calculated measures like sundown time.

The best thing is, that it is so small, that you can install onto a raspberry pi, or you can install it via container into your Synology NAS.

But the downside of this is, that this will get a Hobby that will overwhelms you very quickly, so be careful full ;)

Adding the extension to communicate with the Alexa devices

Homeassistant has plenty of extensions available. So one of them is the Alexa media player. This will discover then all Alexa devices in your amazon account and will enlist them than in your Homeassistant.

First of all, add the integration into your Homeassistant

Next, it will require the log in credentials for your amazon account. It will then generate an SSO Token to get connected through your amazon account to send messages to your Alexa devices and also discover telemetry data from these.

Once installed, you will see in the integration section of Homeassistant a nice tile with the Alexa Media player and their discovered devices.

Also, it will enlist also a multiroom device. A Multi-room device is a group of devices that you can combine together. For example, you can create a multiroom called "everywhere" and add every Alexa you have to this multiroom. For my requirement, it will be perfect, because I want to get noticed everywhere, not only in the garden. Let's assume I am on the roof behind a closed door, there is no chance to hearing the doorbell, but there is an Alexa too, for playing music, while I iron my clothes (yes I do it myself ;)).

Our first try

First, try out that your connection is correct and you can make a Text to Speech message through your Alexa. For this go to your Homeasssistant under Development tools and then on Services. Switch now to the Yaml mode and paste in the following lines of YAML code.

Let me explain the first line. This will use the "notify"- action and address the destination after the first dot.

The template for this is always "notify.alexa_media_{device-/multiroomname}". So this case we send it to the multiroom device everywhere.

The rest is self-explained.

So when you hit the button execute service, you will get noticed by your Alexa.

Let's integrate

After our first test will be successful we can integrate them into our Homeassistant for now. Instead of creating awful hacky scripts, I will use simple automation for this.

So go to Settings and then Automations and create a new one. As a trigger, you can use anything you have available. My doorbell sends a message to the MQTT on a specific topic. So I will listen to it. Here's my trigger definition

The YAML definition is here

After we have a trigger, there must execute our call, so go to the actions and add a new one. This will then execute Text to Speech action like above. So I modified the text for our announcement a little bit and it will look like this.

Please note, that I live in Germany, so my device name differs from the one above. The important part is the data part. Here I will tell Homeassistant to use the announcement and use the voice to announce (with speech). So the yaml for this action looks like this:

Now you can save them and hit execute. After that, you will hear your Alexa telling you that someone is at your front door.

Final Words

So I now have my custom digitalized doorbell extended with the functionality to speak. So in that case I am in my garden or in a room, where I cannot hear the doorbell, I will get noticed through Alexa. After a little tryout with my homeassistant, I found this very helpful. Yes sure there are other ways too, but this was very seamless for me.

The other thing is, that I now have a use case to integrate my Alexa devices into my Homeassistant for now. Sure you can use these Alexa announcements for more than the doorbell notification. Maybe for presence detection, to let Alexa greet them when they come into the door. But for me, it is enough that Alexa will tell me that the package delivery guy (or another person) is at the front door.

How I pimp my PowerShell

Der Sascha — Fri, 10 Jul 2026 13:59:27 +0000

Originally published on my blog: https://blog.bajonczak.com/how-i-pimp-my-shell/

Every developer uses the shell, but why use the old-fashioned style of the shell.

I prefer to use PowerShell, of course, you can use bash and other terminals instead. But this article is written for this (it can be also applied to another shell too).

My goals

To the fact, that I use git repos, I want to know the following information about the current directory:

On which Origin I am working
in which branch I am working on
Are there actual changes
Is there s.th. to push

So actually I want this Information in my (Power)Shell CMD.

Using Oh My Posh

Oh my Posh is a pendant to oh my bash. It is an extension for your shell that will gather some information about what you will need. It’s configurable and also themeable. So that you can design your shell (later) on your needs.

So first of all, I must install the shell itself:# Windows

After that you have successfully installed you can immediately execute oh-my-posh.exe

Yes, you look right, it’s a binary executable. But now worry about it, we now integrate it now in your shell

Integrating it into your existing shell

So the executable is nice to have, but we want the information just in time while we open up the cmd line and on every single prompt.

So let’s integrate it into your (Power)Shell. Luckily you can use in the Shell a profile to integrate custom scripts, so we open up the profile in vs code withcode $PROFILE

In some cases, there does not exist any profile, so it will create one. with the name Microsoft.PowerShell_Profile.ps1 . Maybe some profile contains some content, in this case, you can attach the next lines below the existing scripts (if you don’t care about the order of executions).

First of all, you must import the required PowerShell Modules for oh-my-posh:Import-Module oh-my-posh

When you will ensure that you install the module before it will be imported, you can use this at the top of the profileif ((Get-Module -ListAvailable -Name oh-my-posh) -eq $null) {Install-Module oh-my-posh -Scope CurrentUser -AllowPrerelease}

Now now you can add the command that must be executed before each command line will be shown up, let’s use the default one, to see quick resultsoh-my-posh --init --shell pwsh --config ~/jandedobbeleer.omp.json | Invoke-Expression

This command will execute oh-my-posh and uses the default config “jandedobbeleer.omp.json”.

Now execute . $PROFILE to reload the profile itself, to take effect.

So far so good, but the shell is very…yeah … ugly. Because there are some squares in it and that looks very unfriendly.

This is because you use a font, that does not support any symbols that oh-my-posh uses. To solve this, I use Caskaydia Cove from Nerdfonts. This font collection uses the “free” font spaces and fills them up with some fonts from Fontawesome, Devicons, and so on. For more information about please go to the page.

After assigning the new font, and a quick restart of the shell, you get the new look like this

Set custom configuration

Now the default prompt has some information that we don't want. So let’s customize this to our needs (defined above). Modify the cmd in your profile to use a custom configuration file:oh-my-posh --init --shell pwsh --config $HOME/ohmyposh/myconfig.omp.json | Invoke-Expression

Now let’s open up the config code $HOME/ohmyposh/myconfig.omp.json and past the default config into it:

After a reload of the config, . $PROFILE you will be prompted with a minimal shell.

Customize the cmd line

The first thing we customize is the shell itself. So I want the current time, the current directory first. This will do in the segments area in the JSON configuration file. So each information will be a segment. Let’s add:

The current time
The current folder

So I added a segment for the current time (and formatting of these)

After this I added this segment to display the current folder:

Now it will look like this:

Add git Information

To add the git information you will add the git segment for this:

This contains some custom formatting. In general, the segment will display the changes with the following representation.

+ Added
~ Modified
- Deleted
? Untracked

This will be displayed as follow:

It will now display that the folder has open edits. 4 new Files that must be added and 8 Files that will be deleted.

After this, you have all information you will need. You can also add more segments, have a look at the existing segment definitions here.

Expert level: Tooltips

So maybe if you like to add more and more segments, your command will get messy. In that case, you can use Tooltips instead.

To enable them you must add Enable-PoshTooltips after the oh-my-posh command. That will rebuild the tooltip collection.

Tooltips will display the extension depending on your typed command. Here is an example for git

To add a tooltip you must add it into the tooltips area in the configuration.

So for git, it will look like this:"tooltips":

so a tooltip uses the properties from the segment definition like above, but it will extend the Properties

tips
leading_diamond
trailing_diamond

In tipsyou can enlist the keywords to act on. So if you enter gi followed by a space, it will execute (shown) the tooltip information. It then displays the information as given in the template. I customized the tooltip for git like this

Final Configuration

For everybody who will use a copy past friendly version, you can use this gist

How to Build an Android App in Azure DevOps

Der Sascha — Fri, 10 Jul 2026 13:59:21 +0000

Originally published on my blog: https://blog.bajonczak.com/how-to-build-an-android-app-in-azure-devops/

When you start to build an Android App in Xamarin, it is very handy to generate an App File for distribution, but sometimes the delivery time will get faster and you must publish very often new app versions with new features.

Azure DevOps will support you in this case. Let me introduce you, to how we can generate a signed app automatically in Azure DevOps

Requirements

When you create an APK-Package for the Android world, you will notice that the apk Files must be signed. For this, you must generate a Keystore file. If you have installed Visual Studio on your system with the Xamarin Development environment, you will get this tool installed. So open up a PowerShell Terminal end execute the following command

After you will execute this, you will be prompted by several questions about the publisher like name and so on. But be careful, the parameter alias name will be required later in our pipeline and please be careful about the validity parameter. This will set the days when the Keystore expires, so when this happens, you will be not able to update the app in the google play store.

So here is my output after I execute the command in my shell

If you wonder how I get this nice command line, look at this post.

Now you have a generated Keystore, that you can use to sign the APK-Files.

Store the Keystore in Azure DevOps

Azure DevOps contains a space that store files securely. So that nobody has access to it, except the users/pipelines that are granted.

To store goto Pipelines->Secure files-> + Secure file. You will get then a dialog like this (I already added the files to the upload section)

After you click OK the file is stored. You can then configure the security (who has access to it) and so on.

Next, we must set a variable group

Setup the variables

A variable group is a container for several variables. It contains visible variables and secret variables (hidden by stars).

I added a variable group called andriodApp. In this group, I added the variables

KeystoreFile
KeyStorePassword
KeyStoreAlias

The variable KeystoreFile is the name of the secure File, that we uploaded before. The KeystorePassword variable contains the associated password to the KeyStore. The alias name, that we defined before, ist stored in the KeyStoreAlias variable.

Now that we have set the common variables that we can use, we can create our pipeline for building the apk file.

Create the Pipeline

I will skip the part to generate an empty YAML Pipeline because this is very intuitive and there are several howtos on the net that describe this better than me ;).

So I use the following pipeline:

You see that at the top we define on which branch the pipeline will trigger and which variable group it must use. Next to it there comes up the deployment steps. These will download the Keystore file we uploaded before. After restoring the required NuGet packages, it will compile the solution and generate the apk package.

Now the important part, the next step will sign the apk package against the Keystore. The rest is only the upload to the artifact store and nothing more. After all, these Packages is ready to use.

Conclusion

With this simple HowTo, you are able to create a pipeline that will compile and deploy an android APK-File. In my other post about generating an ios Package you will see, that is not very different from that process. Sure Xamarin is not very popular, but it helps out in some cases.

Deploy Sharepoint solutions without downtime... Really!

Der Sascha — Fri, 10 Jul 2026 13:59:15 +0000

Originally published on my blog: https://blog.bajonczak.com/deploy-sharepoint-solutions-without-downtime-really/

Hello my fellows, today I think it's time to get very serious about one MS product. Somehow will like it but most developer will hate it... SharePoint On-Premise.

Each developer has it's own preference to deploy the solution. Maybe complete manually with some click adventures, or fully automated with a devops Pipeline. But everyone know, if you deploy a solution, the IIS Server gets restartet, there is now way to go around this. So it seems that there will be no zero Downtime solution possible. But that's wrong. Let me explain how you can archive this.

Requirements

To make it clear, you cannot do a zero downtime deployment in a single server environment. You must have at least two Webfrontend (WFE) Servers. Usually, you have a load balancer configured o make a round robbin distribution of the request so that the load will be divided across all WFE-Servers.

For example, let's assume you have the following simple server structure

When a user now accesses the server, the LB checks if the WFEs are available. If true, then it will send the user's request to the first WFE, and the next request will be sent to the second WFE, the next to the first WFE ..... This procedure explains the round robbin procedure. The important part here is that the LB every time checks if the WFE is available.

So our requirements are

Minimum 2 WFE's
A LB with availability checks

The basic deployment

Basically, a deployment of a SharePoint solution will be done like this

Now the process starts, it will add some assembly to the GAC, and after this, it will send some data to the layouts folder and many more things. After that, the IIS pool will be recycled to get fresh assemblies. These processes will be done across all servers on the farm simultaneously.

The consequence is that every user will be kicked out from the server and maybe get frustrated because he did some work and it could not be saved in SharePoint.

Modified command

Now lets configure the command a little bit

When you execute this command, you will notice that the server (where you executed it) getting down, but the other server will be up. Why?

with the parameter -Local we tell SharePoint to install the new Solution only on the current server only, now you can controll the behaviour of the deployment process. Now the availability checks are important.

So in your example with two WFE you will execute on the first Server the update command with the local parameter. The Server getting down, the LB will notice this and redirecting all traffic to the second WFE. After the installation the server is up again and you can install the package on the seconde WFE. The LB will notice that the second will not be available anymore and redirects the users to the first server. So the user will not notice anything about a downtime because he will everytime gets redirected to the running server.

To warmup the SharePoint and get a faster response you will execute a GET-Request to the server and imitiate a User request to the WFE. After this the server will be reqdy for a fast response.

Conclusion

Now you are able to deply Solution to your farm without any downtime. Because you have a well configured Loadbalancer that will switch automatically between the instances. So your Deployment will concentrate on a single server, after the installation is complete, the next server will be updated. The loadbalancer then will switch between the available server. Sure in a Farm with many WFE Servers your can consider to deploy the solutions in groups. Try it out, you will see that it will get very handy, and support the DevOps lifecycle very much.

What is Microsoft 365 eSignature?

Der Sascha — Fri, 10 Jul 2026 06:35:01 +0000

Originally published on my blog: https://blog.bajonczak.com/what-is-microsoft-365-esignature/

Microsoft 365 eSignature is Microsoft’s native way to request electronic signatures from documents stored in Microsoft 365, mainly SharePoint.

That is the simple description. The more useful one is this: it is a signing workflow built into the place where many companies already keep their working documents. A user can start a request from SharePoint or, for supported Word scenarios, from Word. The recipients sign a PDF copy. The completed PDF lands back in SharePoint.

For many teams, that is enough. For some teams, it is absolutely not enough. The trick is knowing the difference before people start using it for everything.

If you are planning a rollout, use the full Microsoft 365 eSignature guide and the tenant readiness checklist.

What happens in the PDF flow

A user opens an unencrypted PDF from a SharePoint document library, chooses the signing option, adds recipients, places signature fields and sends the request. Recipients get a notification, open the request, accept the electronic signing terms and sign.

When the request is complete, SharePoint stores the signed PDF in the same location as the original file.

That storage detail matters. It means the signed document can follow the same ownership, retention and audit thinking as the rest of the library, assuming your SharePoint governance is not already a mess.

What happens in Word

Microsoft also supports eSignature from Word desktop for eligible users and documents. The Word file must be a .docx, unencrypted and stored in a SharePoint site enabled for eSignature. Users can place eSignature fields directly in Word, then send a request.

The signer does not edit the source Word file. They sign a generated PDF copy, and the completed PDF is saved back to the SharePoint location.

This is useful for repeatable templates such as HR letters, approvals or standard agreements. It is not a full contract lifecycle system.

What kind of signature is this?

Microsoft describes the service as using simple electronic signatures.

That sentence should make legal and compliance teams pay attention. Simple electronic signatures are perfectly fine for many business processes, but they are not the answer to every regulated, high-risk or identity-sensitive scenario.

Before rollout, decide which document types are allowed and which must stay with a stronger or more specialized signing platform.

Why admins should care

This feature leans heavily on SharePoint and Microsoft Entra behavior.

The sender needs edit and sharing rights. External recipients may require Microsoft Entra B2B integration for SharePoint and OneDrive. Site sharing, unique permissions, sensitivity labels, conditional access, encryption and download restrictions can all affect whether the process works.

So yes, it is an eSignature feature. But operationally it behaves like a SharePoint governance feature. The SharePoint eSignature governance guide goes deeper on that.

Audit trail

Microsoft says eSignature activities can be searched in Microsoft Purview Audit. Useful events include request created, sent, canceled, declined, expired and completed. Recipient actions such as viewing, signing and downloading the signed document can also appear.

For Microsoft 365-heavy organizations, that is one of the better arguments for the native option.

When it is a good fit

Microsoft 365 eSignature is worth considering when:

the document already lives in SharePoint;
the signing flow is simple;
simple electronic signatures are legally sufficient;
up to 10 recipients per request is enough;
the signed copy should stay in Microsoft 365;
the organization wants Purview audit visibility;
buying another signing platform would be overkill.

When I would be careful

I would be careful if the process needs advanced identity checks, heavy templates, complex routing, bulk sending, CRM integration, legal negotiation workflows or strict regulated signing requirements.

In those cases, compare it properly against Adobe Acrobat Sign and DocuSign instead of forcing every use case into the Microsoft-native tool. I covered that in Microsoft 365 eSignature vs Adobe Sign vs DocuSign.

Bottom line

Microsoft 365 eSignature is not magic and it is not a universal replacement for dedicated signing platforms.

It is a pragmatic option for simple signing workflows that already belong in Microsoft 365. Used that way, it can reduce friction. Used without boundaries, it becomes one more thing admins have to clean up later.

Microsoft 365 eSignature Guide: Setup, Licensing, Governance and Troubleshooting

Der Sascha — Thu, 09 Jul 2026 17:10:06 +0000

Originally published on my blog: https://blog.bajonczak.com/microsoft-365-esignature-guide/

Microsoft 365 eSignature sounds like a small feature. Open a document, request a signature, store the signed PDF back in SharePoint. Done.

In real tenants it is never quite that small.

The moment you enable it, you touch billing, SharePoint sharing, external guests, document permissions, legal acceptance of electronic signatures, audit logs, sensitivity labels and support. That does not make the feature bad. It just means it needs to be rolled out like an admin feature, not like a nice new button in Office.

This hub pulls the pieces together.

The articles in this hub

What is Microsoft 365 eSignature? explains what the service actually does, where the signed document goes, and why the SharePoint integration matters.
How to enable Microsoft 365 eSignature in your tenant covers prerequisites, pay-as-you-go billing, the admin center setup and the checks I would run before a pilot.
Microsoft 365 eSignature licensing, pricing and limitations looks at the request-based billing model, the current Microsoft-listed USD $2/request price and the limits that can surprise people.
Microsoft 365 eSignature vs Adobe Sign vs DocuSign helps decide when the Microsoft-native option is enough and when a dedicated signing platform is still the safer choice.
SharePoint eSignature setup and governance is the admin-focused part: sites, owners, sharing, labels, retention and audit.
Common Microsoft 365 eSignature problems and troubleshooting gives the service desk a starting point for missing buttons, failed external signers and permission problems.

Downloads for the rollout

How I would use this hub

If you are just evaluating the feature, start with the overview and pricing articles.

If you are the admin who has to enable it, read the setup and governance articles first. The setup itself is not complicated. The messy part is deciding which sites are allowed to use it, who can send requests externally and what happens when a signer cannot access a document.

If procurement or legal is asking whether this replaces Adobe Sign or DocuSign, do not answer with a simple yes or no. The honest answer is: sometimes. Microsoft 365 eSignature is a good fit for simple SharePoint-native signing flows. It is not automatically the right fit for advanced contract workflows, regulated signing, bulk send scenarios or heavy template automation.

My take

I like the direction Microsoft is taking here. A lot of companies already store the document in SharePoint, discuss it in Teams and audit it through Microsoft 365. For those companies, sending basic signing work out to another platform can feel unnecessary.

But I would not enable this tenant-wide on a Friday afternoon.

Start with a pilot. Pick a few sites with owners who actually care. Test internal and external signers. Watch the billing meter. Check the audit log. Break it on purpose with labels, permissions and conditional access. Then decide where it belongs.

That is the difference between a useful Microsoft 365 feature and another uncontrolled workflow hiding in SharePoint.

Sources

This guide is based on Microsoft Learn documentation for Microsoft 365 eSignature overview, setup, pay-as-you-go pricing, Word/PDF signing, Teams Approvals tracking and troubleshooting.

Microsoft 365 eSignature vs Adobe Sign vs DocuSign

Der Sascha — Thu, 09 Jul 2026 11:29:14 +0000

This is not a religious debate. It is a workflow decision.

Microsoft 365 eSignature is attractive when the document already lives in SharePoint and the signing process is simple. Adobe Acrobat Sign and DocuSign are stronger when signing is part of a larger agreement process with templates, routing, identity options, integrations and reporting.

This article belongs to the Microsoft 365 eSignature guide. If you need a reusable decision artifact, download the comparison table.

The short version

Use Microsoft 365 eSignature when you want a simple Microsoft-native signing flow and the signed document should stay in SharePoint.

Use Adobe Acrobat Sign when PDF-heavy workflows, Adobe tooling or mature signing templates are already part of the business.

Use DocuSign when agreements are a serious business process rather than a document with a signature field.

That is oversimplified, but it is a decent starting point.

Comparison table

Area	Microsoft 365 eSignature	Adobe Acrobat Sign	DocuSign
Best fit	Simple SharePoint-native signing	PDF-heavy enterprise signing	Advanced agreement workflows
Storage model	Signed PDF returns to SharePoint	Provider workflow with Microsoft integrations	Provider workflow with Microsoft integrations
Microsoft 365 integration	Native SharePoint, Word, Teams Approvals and Purview audit	Strong Microsoft 365 integrations	Strong Microsoft 365 integrations
Pricing shape	Pay-as-you-go per request	Plan/licensing dependent	Plan/licensing dependent
Governance model	SharePoint and Entra governance matter heavily	Provider admin plus integration governance	Provider admin plus integration governance
Advanced templates	Limited compared with dedicated platforms	Strong	Strong
Bulk send and routing	Not the main strength	Stronger	Stronger
Best admin argument	Keeps simple workflows inside Microsoft 365	Mature PDF signing ecosystem	Mature agreement workflow ecosystem

Where Microsoft 365 eSignature wins

Microsoft wins on proximity.

The document is already in SharePoint. The user is already in Microsoft 365. The signed PDF comes back to the same place. Audit activity can be searched in Microsoft Purview. Teams Approvals can help users track requests.

For common internal approvals, HR forms, policy acknowledgements, procurement documents or low-complexity external signing, that is a strong story.

It also reduces tool sprawl. If a process does not need a dedicated eSignature platform, keeping it inside Microsoft 365 is cleaner.

Where Adobe Sign and DocuSign win

Dedicated platforms win when signing is not the whole process.

Think reusable template libraries, conditional routing, bulk sending, advanced recipient authentication, branded experiences, CRM integration, contract operations, APIs, delegated administration and reporting. That is where Adobe Acrobat Sign and DocuSign have had years to mature.

If sales, legal or procurement already run critical workflows through one of those platforms, do not rip it out just because Microsoft added a native option.

Governance is different, not gone

Microsoft 365 eSignature pushes governance into SharePoint and Entra. Site permissions, guest access, sharing restrictions, sensitivity labels and conditional access all matter.

Adobe Sign and DocuSign push more of the workflow governance into the provider platform. You still need Microsoft integration governance, but the signing process itself is usually managed in the signing product.

Neither model is automatically better. The better model is the one your organization can actually operate.

My recommendation

I would define three buckets:

Microsoft 365 eSignature for simple, SharePoint-native signing.
Adobe Sign or DocuSign for advanced, regulated, high-volume or customer-critical workflows.
No eSignature tool at all for things that should just be an approval, a form or a workflow task.

That third bucket matters. Not every “please confirm this” needs a paid signature request.

Bottom line

Microsoft 365 eSignature will not kill Adobe Sign or DocuSign. It does not need to.

Its job is to cover the boring but useful middle: documents already in Microsoft 365 that need a simple signature and a signed PDF back in SharePoint. Use it there and it makes sense. Push it into every workflow and you will eventually regret it.

Common Microsoft 365 eSignature Problems and Troubleshooting

Der Sascha — Thu, 09 Jul 2026 11:29:01 +0000

Most Microsoft 365 eSignature problems are not mysterious. They are usually SharePoint, permissions, external sharing, file format, labels or conditional access showing up as an eSignature issue.

That is annoying, but it is also good news. You can troubleshoot it with a method instead of guessing.

This article is part of the Microsoft 365 eSignature guide. Keep it next to the tenant readiness checklist and the SharePoint governance guide.

The signature option is missing

Start with the obvious checks:

Is eSignature enabled in the Microsoft 365 admin center?
Has it been less than 24 hours since activation?
Is the document in a SharePoint site enabled for eSignature?
Is the user opening the PDF from the SharePoint document library viewer?
Did the user open the file in Edge, Adobe Reader or another viewer instead?
Does the user have the right permissions?

Microsoft’s troubleshooting guidance is clear on one point: the PDF viewer must be opened by selecting the PDF from a SharePoint library. If the user opens the file another way, the signing option may not appear.

The user cannot create a request

Check the document and the folder first.

Does the sender have edit rights?
Does the sender have sharing rights to the folder?
Is the PDF under 10 MB?
Is the PDF unencrypted?
Are site sharing settings restricted to owners?
Is the document in a private group where the sender cannot share?
Are DLP, sensitivity labels, encryption or access policies blocking the flow?

Also check whether the document was previously signed. Microsoft says new eSignature requests cannot be started from documents that were already signed.

External recipient cannot sign

External signing issues usually come down to guest access or conditional access.

Check:

Is external sharing enabled at tenant and site level?
If new external guests are allowed, is Microsoft Entra B2B integration for SharePoint and OneDrive configured?
Are domain restrictions blocking the recipient?
Is conditional access blocking the eSignature app or the guest flow?
Did the signer receive the email?
Did the message land in junk or spam?

Microsoft notes that admins may need to review conditional access behavior for the Microsoft eSign service. Be careful here. Do not punch a broad hole in conditional access just to make one document work. Test the policy change with security involved.

Adobe Sign or DocuSign request fails from SharePoint

When you start a request for another provider from SharePoint, the provider may need to open or download the document. Encryption, download restrictions and access policies can block that.

Check:

Is the document encrypted?
Is download blocked?
Does the sender have permission to download the file?
Is the provider integration authorized correctly?
Does the provider support the document state you are sending?

If users keep hitting this, revisit the tool decision. The Microsoft 365 eSignature vs Adobe Sign vs DocuSign comparison can help.

Signed document cannot be accessed

Microsoft checks whether the sender can write to the original location before and after signing. If permissions change while the request is in progress, the completed document can become hard to access.

Check:

Does the sender still have access to the originating folder?
Was the file moved during the signing process?
Did someone change library or folder permissions?
Is the completion email offering temporary access?

This is another reason to avoid running signature workflows from chaotic libraries.

Quick PowerShell check for site sharing

Microsoft’s troubleshooting article suggests checking SharePoint site sharing capabilities with SharePoint Online PowerShell:

Connect-SPOService -Url "https://yourtenant-admin.sharepoint.com"
Get-SPOSite -Limit All | Select-Object Url, SharingCapability

This is only a starting point. Tenant and site settings can look fine while folder permissions, labels or conditional access still block the process.

My triage questions

When someone reports an issue, ask these first:

Which SharePoint site and library contains the document?
PDF or Word?
Is the file encrypted or sensitivity-labeled?
Internal signer or external signer?
Existing guest or new external recipient?
Does the sender have sharing rights?
Can the issue be reproduced with a clean test document?
Do Purview Audit events show anything useful?

That list will solve more cases than a long call full of screenshots.

Bottom line

Troubleshooting gets much easier when the rollout is designed properly. Approved sites, clear sharing rules, tested labels and a support path remove most of the chaos.

If the tenant is already messy, Microsoft 365 eSignature will not create the mess. It will reveal it.

SharePoint eSignature Setup and Governance

Der Sascha — Thu, 09 Jul 2026 11:28:42 +0000

Microsoft 365 eSignature looks like a signing feature. Admins should treat it as SharePoint governance.

The signing flow depends on the boring stuff: site permissions, sharing settings, guest access, labels, encryption, conditional access, ownership and retention. If those pieces are messy, eSignature will expose the mess very quickly.

Use this article with the Governance Template and the full Microsoft 365 eSignature guide.

Do not start tenant-wide

The first governance decision is scope.

I would not enable every SharePoint site on day one. Start with a pilot group of sites where the business owner is known, the document types are clear and the permissions are not a museum of old projects and broken inheritance.

Put sites into buckets:

approved for eSignature;
pilot only;
blocked until ownership is fixed;
requires legal or compliance review first.

If a site has no owner, it should not send signature requests. That rule alone prevents a lot of pain.

Decide who can send requests

The sender needs edit and sharing rights. In many SharePoint sites, that describes far more people than admins realize.

Define the model:

Can all site members send requests?
Should only site owners or a dedicated group send them?
Are external requests limited to certain teams?
Are some libraries excluded?
Does legal need to approve certain document types first?

If the answer is “we will see how people use it”, you are already choosing cleanup work later.

External signing needs real rules

External signing is useful. It is also where many problems start.

Microsoft notes that external recipients who are not existing guests require Microsoft Entra B2B integration for SharePoint and OneDrive plus guest sharing. That means your guest access and sharing posture are part of the eSignature design.

Decide:

existing guests only or new guests allowed;
allowed and blocked domains;
conditional access behavior;
guest lifecycle and access reviews;
who supports external signers;
which document types may be sent outside the organization.

Do not let every site invent its own answer.

Test sensitivity labels before users do

Sensitivity labels and encryption are exactly the kind of thing that look fine in a policy document and then break a workflow at the worst time.

Test the labels your users actually apply. Test encrypted documents. Test restricted download policies. Test documents in libraries with unique permissions.

If a label blocks signing, that may be correct. The point is to know before someone is trying to get a contract signed at 16:55.

Plan where signed PDFs live

The completed signed PDF is stored back in SharePoint. Good. But which SharePoint location is the record?

Decide:

whether signed PDFs are records;
how long they are retained;
whether users can move or delete them;
whether metadata is required;
whether source documents and signed PDFs follow the same retention;
who owns cleanup when a department reorganizes.

This is not glamorous work. It is exactly the work that makes the feature safe.

Use Purview audit

Microsoft says eSignature events can be searched in Microsoft Purview Audit. Track events such as request created, sent, canceled, declined, expired, completed, viewed, signed and downloaded.

At minimum, admins should know how to answer:

Who sent this request?
Who signed it?
When was it completed?
Was the signed document downloaded?
Did the request fail or expire?

If nobody can answer those questions, the rollout is not ready.

Prepare support before launch

The common tickets will be predictable:

missing signature option;
PDF too large or encrypted;
user opened the PDF outside SharePoint;
sender lacks sharing rights;
external signer blocked by guest or conditional access settings;
signed document cannot be saved because permissions changed.

Point support teams to the troubleshooting guide and give them a test site where they can reproduce issues.

My baseline policy

Enable eSignature only for sites with an owner, a defined document scope, tested external sharing behavior, known retention expectations and a support path.

If that feels strict, good. A signature workflow creates business evidence. It should not live in an ownerless library with mystery permissions.