Windows Server 2016 and 2019 RDS

Have I missed documentation somewhere? Doesn’t matter how many permutations I’ve tried of reboot, install, delete user AppData and or system32 AppData, login logoff, stop and start the service, when I login as the second RDS account I get

Tailscale already in use by SERVER\login, PID nnnn

This is for multiple users on an @companydoman not single user.

Each combination of machine/user shows as a different IP in the admin console, so I’m leaning toward something odd in the way the Tailscale service is reading machine and user ini’s.

Yes, used change user /install /execute where appropriate. There may also be a non-Tailscale issue, by very lateral inference, connected with the RDS SessionManager service.

After having gone down every vaguely related rabbit hole that DDG would give me, I decided to see if a workaround was possible.

After a few dead ends, changing the Advanced Properties of the shortcut

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Tailscale

so that

“C:\Program Files (x86)\Tailscale IPN\tailscale-ipn.exe” /client

ran as Administrator, causing each login from different accounts using RDS to pick up the Administrator AppData ini, soz config, entry, thus all connected to Tailscale as one identity.

It doesn’t seem to cause any problems with all the parallel RDS sessions logged in together.

Rebooting the Win Server 2016 (in this case) did cause a hiccup though.

Immediately after reboot, no accounts have logged in, and it appears the tailscale-ipn.exe is just hanging around waiting and none of the CGNAT address range that Tailscale uses are avilable.


Have to have at least one account log in to the server at boot to wake tailscale-ipn.exe up.

This is getting icky.

An autologin account is fairly nasty, Sysinternals do at least allow the password to be a little bit encrypted in the registry

So I’ll try creating a Guest account locked down in the seventh level of hell, on top of all the usual Guest restrictions, profile deletions, yadayada, for autologon and does nothing but allow Tailscale to start with a single Identity, so the 100dot address of the server will be available and other RDS accounts will then be able to login using it.

If that works, I might try a stub “tailscale-ipn.exe /client” service with “Allow service to interact with desktop” and maybe login as the Guest account. Dunno, probs clutching at straws here.

A very, very long way from elegant.


We’re not quite sure what you’re trying to do. On any given Windows system, there can only be one copy of the Tailscale GUI running at once, because a machine can only have one IP address at a time.

Tailscale allows each user who logs into a given machine to have a different IP address, so that the IP address can be used to identify the user. However, it still only lets one person log in at a time. One user will have to log out before the next can log in.

If you have a machine with multiple users who need to log on at once (eg. Windows Terminal Services), you can log into Tailscale once as any user, then right click the Tailscale icon and pick “Run unattended.” This will force that instance+login of tailscale to start even before any user logs in in the future, and prevent any other users on the system from trying to change Tailscale settings. I suspect that’s the mode you’re looking for.

Hope this helps!

Cool, I’ll try that now. What I thought I needed was to have each RDS user connect with the IP that was their association with the server that was running the RD SessionHost, I’d misconstrued it.

Will get back to you when I’ve got a result. Cheers.


Ok, this is waaaaay cool. Thank you. It works.

I got into the tailscale code on Github for a while, but the port to Windows is obvs still delicate in this area, so the only thing I’d like to pass on to your dev team, is that from a Win perspective, particularly RDS, I’ve got a linux background too but both are biased by my history as an IBM systems programmer, the device itself needs an IP address before any user sessions are initiated. Having a user whose sole task is to establish a conceptually static IP for the device to allow other users to find the device before they log in is a high order kludge. This won’t be simple to fix elegantly even though a service started at boot would be an obvious solution. Microsoft are doing interesting things in the area of removing services from having desktop, read user AppData profile access.

Anyways, now I’ve got a workable solution, I have to start on the sales pitch to my clients. This is not my comfort zone. At all.

Tailscale’s a fabulous solution to so many problems. Even from a systems perspective, it’s nigh on magic the way it makes legacy tech securely useful again.

There’s a background to why I was looking for a particular solution, I’ll post it following this as a separate entry so it can be ignored as pretty much irrelevant to this specific topic.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

This is the separate entry so it can be ignored as pretty much irrelevant to the specific topic.

To make my sysadm life tolerable, I map every interaction based on a device organisation person role service model which works more or less with most traditional ways of modelling corporate designs.

I’ve done some things with the my model though, to allow me to rejig relationships between each of those basic constructs top down or bottom up without breaking stuff. Well hopefully not too badly, it’s still a WIP.

So they all exist as a







a = construct[rand()]

b = one to many

c = a||b

d = many to one

e = construct[rand()!=a]

a b c d e


Yup, I do have a soft spot for temporal 6NF database design.

There’s no rules to say any relationship can’t exist, but IRL folx only see some of the rules as reasonable, mainly due to the way language implements restrictions in our thinking. In my case English caused a lot of problems initially. In my albeit very limited experience, native thinkers of dialects that have a written expression in 漢語 similarly with עִבְרִית and I suspect the endonymically فارسی connected dialects, tend to have a different view of what consitutes a sensible relationship or one that’s absurd.

All this came about from the group of, tiny by international standards, SME’s who are my clients, who continually have hare-brained notions about restructuring their businesses, starting new ones, and spinning off potentially sellable parts, and moving staff between the business units on a part time during the day basis and providing adequate accounting of the costs.

A total administrative nightmare from the deeper regions of hell.

This led me to a layered administrative ownership of every business unit construct, which worked fine with a Personal, Local, Systems, Domain, Forest concept. I eventually needed a Goddess layer above Forest, read that as above Federated if you prefer, level which surprisingly fitted very well into the model, even when looped back to the extant structures to allow one meatbag to express multiple social instances without breaking any legal strictures. Being trans helps a lot with understanding this.

My tentative solution to the Tailscale IP for a device, before IP for a deviceperson, (machine, machineuser in your argot I think) becomes available, is to define a conceptual mesh network local administrator role on every device which is a, login once to set up the “Run unattended” thingy, then can be ignored from then on. Except it has to stay there forever on the login screen, and I’ll get continually pestered about why it exists and why it can’t be removed.

Will try to keep a close watch on yor forum, Github, and Twitter PointsOfPresence (?!) for where this goes. I get that’s it’s not a specific problem that I can file a bug report for, more a general, this is pretty much how we can make the cross-OS thing work.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

There’s distinct echos of SNA trying to incorporate LU6.2 into itself here. Reckon y’all have got it right though.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Excellent documentation y’all have put up recently on the Windows Server and RDS areas. Covers it very clearly. Thank you.