Roaming profiles not replicated across domain controllers?

UCS - Univention Corporate Server
1

Short variant: I don’t see that roaming user profiles get replicated across primary and backup domain controllers: shouldn’t that be done automatically?

Long variant:
Last time I created Windows domain controllers was with Windows NT 4, I avoided AD for its entire life time, just so you know where I am at.

I’ve stuck with workgroups and local profiles whenever I was stuck with Windows, because I was afraid of all those “forrests” and “trees” and having to go too deep for my relatively trivial personal use cases.

And did I mention that I “grew up” on diskless Sparkstations with an NFS root allowed you to roam transparently between devices?

And later I used X-terminals both for Unix and for Windows (via a Citrix derivative by Tectronix).

The latter offered the same user experience as the Sparcstation, even for Windows, a single roaming desktop no matter which physical access device you were using…

Obviously with Windows I now expect the same, except it should now also support disconnected mode via a laptop, made possible by roaming profiles and automated folder synchronization, right?

Since Univention is the better AD, I’ve stuck my neck out and am taking baby steps with Windows clients.

And since I’d seen mentions of “replication” for domain data in the documentation and I well remember that even on NT3.51 and NT4 you’d use backup domain controllers for resilience, I was naturally assuming that a single point of failure for domain controllers would never exist with Univention either.

I don’t have logon scripts or custom policies yet, but I would like to use roaming profiles with my various Windows clients, many of which are VMs.

So I had three DCs set up, one primary and two secondaries for use with LDAP/Linux for a while now, all nicely replicating LDAP.

And then I added AD and started to join my first Windows client, which went well enough (actually I tried it all in a set of VMs first with only a single DC).

Color me surprised that I couldn’t simply transfer a local profile to a roaming one, but that’s a different topic.

So I created a new domain user profile to my liking and then marked that “roaming” and logged off. That took a nice long time to copy all that profile data on the logon server, which happened to be the tertiary or 2nd backup DC in this case.

But that didn’t get replicated to the primary and the backup controller. Actually there were partials there, evidently from the other machine (a VM) which I was using to test the roaming, but not the full profile from the primary machine.

I was then hunting for any sign or trace of a process that would copy the profile data analogous to how the SYSVOL portion of the DCs gets copied…

And I couldn’t find any.

So what’s going on here? How are you supposed to ensure that roaming profiles remain consistent across logon servers?

2

OK, so I just didn’t get the news, I guess:

After some testing and reading I conclude: roaming profiles are so severely broken on newer Windows releases, that you shouldn’t bother using them.

Perhaps that needs a caution in the Univention manual.

3

Same here, but there is a workaround.
All you need is a NAS, or even a Raspberry Pi would make it, providing a share to your domain. So get the NAS joinig your domain, create a share like \\myNAS\profiles and maintain the user permissions.
As the NAS is running 24/7 it will handle your user profiles.
On a Windows machine run RSAT and create a GP to redirect the profiles to the NAS like \\myNAS\profiles\%username%
Please mind: Enabling the roaming this way will also redirect all user folders!
Recon: Redirect the user folders to a separate share on your NAS!

4

I’m running Univention on an HCI infrastricture, which is a 3-node Proxmox cluster that includes Ceph. The idea is to have it fault-tolerant and eventually distributed (as the kids move out), where they would either have again a single server, or again clusters, depending on the criticality of the IT services in their households.

Having redundant domain controllers only to create a single point of failure for the shared profiles just doesn’t make any sense whatsoever and Microsoft evidently includes a file replication for windows profiles via DFS to match that.

For Samba that’s listed as a future feature (which might never come), so I was assuming that Univention implemented some type of rsync, as they do for the login scripts and policy files…

Anyhow, after I found out that some of my profiles are 800GB, because some of these ML tools install models into the roaming profile directory, I realized that unless WINLOGON did some really smart replication (which evidently it doesn’t), this wasn’t going to end well…

I found User Profile Wizard and Transwiz from forensit.com and with that I can at least convert between local-local and local-domain profiles as well as create copies and templates and that will have to do.

Microsoft just broke Windows so badly in their permanent quest of emulating the fruity cult, that this notion of a follow-me workspace remains an illusion probably 40 years after it’s been demonstrated elsewhere.

Again, there is little Univention can do here except insert a warning, that roaming profiles do not get replicated among the domain controllers and that they are an idea wronged by Microsoft themselves

Ceph provides a wonderfully redundant file system, which would be perfect for roaming profiles… if it supported SMB shares.

Supposedly that’s a feature in progress also with the Ceph people (no arrival date either), in theory exposing it via NFS-ganesha could work even with Windows clients, but ultimately CephFS lacks ACL support, which only XFS and ext3 deliver currently. And that might be needed to avoid huge security gaps.

GlusterFS could have done ACLs, too, also lacked a native Windows client but that’s a dead zombie and not going anywhere.

There is a ton of 90% solutions out there, but in the end the only way to get a persistent destop across devices is to use terminal services.

Now getting those to be fault-tolerant is a different matter, auto recovery a lot easier to achieve and probably good enough.

5

Just in case anyone else dares to travel that same road:

Using CephFS inside Windows turned out to be surprisingly easy: installing Dokan and the Ceph binaries sent swimmingly and getting access to the Ceph cluster mostly involved copying the critical parts of the ceph.conf file from the ones found on the Proxmox server.

Even performance wasn’t too bad, using 10Gbit Ethernet and NVMe drives all around gave me 500MB/s read and 400MB/s write performance from a Windows VM I used for testing, quite acceptable for a 3-way replication setup.

But it’s not just ACLs that are missing with CephFS, user IDs in Ceph are managed via cryptographic keys which nothing in Univention will manage for you, the default setup had everyone on the Windows machine operate as root on Ceph: the abstraction gaps between Ceph and Windows in terms of file sharing are perhaps just too big to close in a manner that provides the minimum of comfort and security both part-time administrators and users expect from a Univention software appliance used at home, in a club or in a school.

I’ll go with a member server exposing disks hosted on Ceph via SAMBA and NFS, which isn’t as naturally redundant and fault tolerant as Ceph or Gluster, but much less complex to operate… or so I thought.

Other issues in other posts…

1 Like
6

We found roaming profiles frustrating ever since Windows 10 was implemented into our system. After many attempts to get it to work we finally moved away from the idea.

In our case Nextcloud came as a meaningful way of delivering always available shares and personal files. It connects to the AD providing user authentication, serves as ACL and allows direct access to remote shares (I believe Ceph can be mounted as an external share). Add Nextcloud client and there’s seamless integration for the user, regardless of the platform.
Maybe that’s something what would ease your problems?

1 Like
7

The integration of NextCloud and other applications like that was one of the primary reasons I started using Univention.

But the fact that most of these “integrated” applications aren’t available ready for use two to three years after alpha and beta releases of Univention 5.2 launched nor months after the final release, seems to indicated that there is something seriously wrong in the relationship between those companies.

I get an “update available” notifcation practically on every interaction with Univention, only to have it disappear once it notices that the NextCloud for Univention 5.2 still isn’t available with the open Github issue seeing no action “for lack of resources”.

NextCloud has grown into a rather mixed bag of functionalities, for files I mainly see its benefit in a somewhat smarter replication facilities, while collaborative editing and video conferencing are definitely very useful, if they work.

The company is bent on making AI agents work, something I find ever less useful the more time I spend with LLMs, I’d rather have them fix the Univention integration first, while NextCloud may not want Univention in “their” eco system.

The huge decline in Univention apps between the late 4.*, past 5.0 to the current 5.2 release practically demolish the value proposition of Univention for me, not what we need as alternative to US cloud services.

My current take on Ceph is that it really doesn’t support shared file system semantics enough, something the developers have actually kept hinting perhaps a little too discretely.

I am looking at Syncthing for long-distance replication as an alternative to ZFS remoting or Cephs mirrors, which aren’t giving me the integration I really want:

In my playbook you start with a single (everything with backups of course) and then expand to a 3-node cluster to get local fault-tolerance, while you then add a remote single for disaster resilience and local caching as your network grows. Those singles then again can turn into clusters, even bigger ones, if that’s useful, and the story repeats.

This synchronous (cluster) to asynchronous (replication) behavior is pretty normal, actually I’d even label it “organic” for what people want, but nobody offers it technically (cloud giants would be very unhappy if anyone did). For ZFS I’d have to go with Lustre for clustering, which with its HPC roots doesn’t really fit my hobbyist approach, while Ceph and ZFS don’t talk to each other.

Gluster wanted to go that way at one point, but never managed seamless scaling and died since. Single to double with arbiter or n-way replication worked, but you couldn’t transition from there to erasure coding, which Ceph seems able to do. But at least Gluster carried the true shared file system functionality upward from XFS, which made it perfect for integration with Univention. I used it with oVirt on CentOS at work until all those were killed by IBM people at Redhat.

BeegFS might be closer, but they put a paywall before the asynchronous part, so grass roots mass appeal isn’t what they are interested in.

Very unwisely, I’d say, but those HPC guys don’t think consumer or SME.