DSfW versus OES client
I'm considering implementing DSfW on a new server setup, and I'm trying to determine from the start if I should bother with it at all, especially if there are excessive time wasting complications.
My main reason for it's use would be to get rid of the OES client on PC's and provide SSO to those PC's, which currently have a separate password for the PC and eDir. We don't intend to integrate Windows servers into it at the moment, just the PC's.
DSfW would streamlines PC builds, but adds complexity at the server end.
The OES client has worked well for years and presents few problems. Will I miss anything from the OES client if I go with DSfW?
Which performs better?
What about login scripts?
Has anyone regretted going with DSfW and preferred using the OES client?
As users of DSfW my honest answer is we wish we had gone with Active Directory and used IDM to sync it to eDirectory (You should have an entitlement for this).
There are a couple of reasons why:
- DSfW is not compatible with Azure AD connect - you don't mention what email you use but if you use Office 365 or think there's even the faintest chance you might in the future then this limits your options. We needed to implement Identity Manager with the Azure AD licenses to sync our users to Office 365 - at the extra cost for those licenses.
- There is a defect in DSfW around password changing, I've actually had a SR open about it for over a year!! (https://bugzilla.novell.com/show_bug.cgi?id=1168099)
The issue is when the users password gets changed outside of Windows. For example if the Admin resets the users password in iManager or if the user changes it in SSPR. When this happens any Microsoft account signed in on the PC is broken, the user then needs to go into settings remove the Microsoft account, Reboot, then sign back in to the Microsoft Account. Also the user will be signed out of any browser sessions that they are in. This is, what can only be described as, a massive ballache!
- Backup and Recovery: At last checking you need to get Micro Focus support to help in any disaster recovery situation.
To be fair to DSfW apart from these issues it works well enough and is surprisingly compatible with systems that want Active Directory connections.
In respose to your other questions: you don't have to give up the OES Client, we still use it. So we stil use the OES login scripts etc. We have it configured so that the Windows Domain login takes precidence and then the OES login runs in the background - so the users never see the OES client login. There are setting you need to set in the OES client to make this happen and if this is how you decide to go then drop me a ine and I can provide them to you.
Any other questions drop me a line
DSfW is in my opinion not an alternative to the OES client, but an alternative to Windows AD. DSfW is convenient, when you habe resources like OES servers or other things, which rely on eDir for authorization and rights. Then DSfW integrates that very well and you do not need an extra Windows AD server for Windows management.
If you rely on Windows cloud things like MS accounts, azure etc., you need a real Windows AD server and are probably better with an IDM synchronization solution.
If you just need AD for authentication of users loggging into PCs and to deploy group policies to PCs and users, DSfW does this quite well at no extra cost (except your time to set it up and to maintain it). It works also quite well, to set user rights to shares and files on Windows servers natively. So for the user there is no difference, if a share is situated on an OES or a Windows server.
If you use DSfW just to administate your PCs centrally instead of administrating each PC individually, this alone is worth the time to setup DSfW, if you have more than 3 to 5 PCs to administer in my opinion.
To avoid problems with DSfW after setup, it is vital to define an DSfW administrator, which should also be an full eDir administrator at root level and to not change this administrator later. The setup scripts which need to be run after each major upgrade rely on this initially defined administrator. If you change the administrator you have to tweek these scripts manually - but I think this is now better than in previous versions.
You can use the OES client together with DSfW although that is - I think - not officially supported. You just have to set the "UNC-pathfilter" to OFF in the OES client advanced properties, so you can make a smooth transition to DSfW, without eliminating the OES client in the first step.
If you eliminate the OES client you lose login scripts, but you can instead use Windows logon scripts - the later can be powershell scripts, which give you a broad range of possible commands.
I do not know if CIFS(Windows client) or NCP(OES client) perform better on an OES server. But as stated before you can use both. But do not use the DSfW server itself as a file server; the DSfW server uses Samba as file server and that has performance problems.
My main file servers are Windows servers, which are fully integrated into DSfW.
Thanks Prindl, this gives me more of an idea about DSfW than I got form perusing the docs and forums for half a day. I think I will definitely give it a try 😀
That's a good point about the DSfW server using samba rather than novell-cifs and the performance issues.
I've been PMed the following info about DSfW.
The password change bug below looks like quite a problem. Can anyone confirm if they have also experienced their environment?
- There is a bug around password changing, I've actually had an SR open on this for over a year. The bug: https://bugzilla.novell.com/show_bug.cgi?id=1168099 means that if the user password gets changed outside of the Windows machine - for example if an Admin resets it in iManager or the user changes it with SSPR, then any Microsoft account that is signed in on the machine is broken. To fix it the user then has to go into settings remove the Microsoft account, reboot, then re-add the account in settings. Also any browser sessions that are logged in to anything (facebook, twitter, gmail, onedrive etc.) will be logged out and the user will have to log in again. To put this frankly it's a massive pain in the backside.
- Disaster recovery and backup - there appears to be no way to restore a server in the case of a disaster recovery situation without working with Micro Focus support.
Why not use zenworks and a dlu policy to provide the sso synchronization between edir and local workstation. Zenworks provides so much more.
I only use dsfw currently for various products that require an AD ldap, or for windows server products that require joining AD domain.
*Apparently OES2018.3 dsfw will add required AD properties to support the eDir to AzureAD cloud sync without IDM, but this is only a rumour.
I've used Zenworks DLU before, but it adds more bloat to the PC than the OES client. The installer is massive, and then there was some lag during workstation startup, while the Zenworks server was located. Though maybe there was something not right with names resolution (or SLP ?)
DSfW would be so much lighter from the PC end for SSO, but adds all the complexity to the server end.
To the password change bug I cannot tell you anything because we have disabled the use of Microsoft accounts for our users and if users have to relogin into facebook that wouldn't bother me.
The disaster recovery and backup depends on your setup. It is vital to know, that some information stored in eDir on a DSfW server is not replicated to any other server - so for a disaster recovery you need a valid backup of the DSfW server itself including its eDir database. If you bring up the server after disaster recovery it is essential, that the server is unable to connect to any other eDir server, to avoid overwriting the local eDir database with entries missing the only locally stored attributes etc.. Only if the server is running fine after recovery you can reconnect it with the other network and other Edir servers. And yes there are situations, where you will need the help of MF support.
But I have already once restored a DSfW server (which was in fact a VM running on a Vmware host) just by restoring a full backup of this DSfW server as a VM without any issues. On real hardware that is probably more complicated.
Also the browser sign out is a massive pain. It's not just every session on every website you are signed into - so not just facebook but partner portals, supplier websites - it can also disable the browser sync so your bookmarks stop being backed up. It's quite a nasty bug and it causes grief for users and helpdesk calls.
"I only use dsfw currently for various products that require an AD ldap, or for windows server products that require joining AD domain."
So if you had a MS SQL Server app running on a Windows server in your OES network, that doesn't need AD, would you use DSfW?
The defect you are referring to is https://bugzilla.novell.com/show_bug.cgi?id=1168099 Unfortunately this is still not fixed. The fix is more complicated than expected. When this is fixed, you will be automatically notified.