Fell a tad behind, realized I need some actual Domain Dependent item running Test environment with following configuration:

• OES - Primary eDir Server
• OES-File - File Server
• OES-AD - DSfW Server
• Win-RDSGW - RDS GateWay
• WIN-RDSBKR - RDS Connection Broker
• WIN-SH01 - RDS Session Host 1
• Win-SH01 - RDS Session Host 2

Found out a Windows DC will not communicate with a DSfW server.  Windows cannot read Novell DNS and DNS is critical for AD

I have seen rpcd crashing very frequently on OES 2018 SP1.

Workaround is to set to following in /usr/lib/systemd/system/rpcd.service:

Restart=on-failure
RestartSec=5s

Then run: systemctl daemon-reload

I have seen "only" two rpcd crashes on OES2023 in 42 days thus far.

OES2023 is running stable for us otherwise.

In the meantime we had similar experience, didn't manage to do it with either a 2012R2 DC or a Samba DC :-( .

Next try will be to add a fresh domain with a Windows DC and establish a forest trust relationship. But the documentation (https://www.microfocus.com/documentation/open-enterprise-server/2023/acc_dsfw_lx/bfb32un.html) for this seems hopelessly outdated (still talking about Windows Server 2003 functional level??), so I don't have much hope...

For us the crash easily reproduces as soon as you restart winbind on a joined samba server. This happens since samba 4.15 or 4.16 IIRC and still happens with samba 4.18.

I'm just wondering if you made any progress with this?

Kevin,

Thanks for bringing this back to my attention.  I'm not sure if this will work, as I haven't tried it yet, but if the objective is to move from DSfW to AD completely removing DSfW than if you can run the DOS DS commands against DSfW you should be able to literally write a script to import all the User, Computer and Group information.  I had an incident in the mid 90's where I had to write a script to completely rebuild AD on another server.  Of course this was AD to AD, but as long as you can get the information it shouldn't be a problem to build a Domain Controller from DSfW.  I will see what DOS and PowerShell can see from a DSfW server and start putting together a script.

I have a few big projects on my plate for now so I may not get to it until the weekend.

Hi Eric,

I'm not ready to abandon DSfW (yet)... 

My interest in this thread is because I keep encountering new issues trying to run applications when using a DSfW domain account and was hoping I could throw a Windows DC into the mix.

My DSfW servers began life as OES 2018 and have been upgraded to OES 2018 SP3. Over the past couple of years I've opened a dozen cases with OT tech support but, for various reasons, the cases were closed without the issues being resolved. Out of desperation I spun up a Windows DC and found that when using a Windows domain account I didn't encounter any of the issues I have when using a DSfW domain account.

Okay, I have alluded to various issues so let me provide some examples of the behaviour I experience when using a DSfW domain account:

• The company uses QuickBooks for accounting. Certain tasks cause QuickBooks to crash.
• I cannot activate Microsoft Office.
• I cannot even download Adobe products.

And of course there are other issues not specifically related to domain accounts:

• My Windows servers cannot communicate with DSfW resulting in a total loss of functionality because they cannot communicate with a DC.
• Sysvol cannot be accessed.
• Group Policy doesn't work.
• I cannot authenticate when using an IP address or NETBIOS name.
• ... and on it goes.

My current plan is to upgrade DSfW to 24.3 and hope I don't encounter too many issues doing so. The next step is to deploy a new 24.3 DSfW server and transfer the FSMO roles. If my issues persist, I will be reopening all the unresolved cases I have for OES 2018.x and spend the next six months doing packet traces and taking screenshots.

Hey Kevin,

Pardon my ignorance but what do you need from OES on the Windows side outside of the filesystem?  Are there any OES specific application or services that you need to work on a windows system?

If you only need to access the filesystem would running CIFS or NSS for AD be a simpler solution? eDir and AD will play in their own space but if on the Windows side if your applications do not need to talk to eDirectory and only need to access the filesystem.  Any services you use eDir for you can federate locally on AD and in most cases the OES service already has the ability to connect to AD.  By federating through AD you get the ability to access NSS volumes and seamlessly connect to your external applications and services.

It seems like you already have a DC setup in your environment.

I'm faced with a very similar issue, but I haven't touched OES/Netware in over 20 years until 2 years ago and I have a lot of catching up to do.  This is what I'm looking at:

DSfW - For Domain Services

NAAF - For MFA

iDM - To federate services for Microsoft 365, Spam filtering, Email Archiving, etc

DSfW will provide the Domain type structure, but not the services needed to authenticate with anything else.

I would like to hear more about your journey, as my environment is not as advanced as but maybe we can be of assistance to each other to find answers.

Eric Robinson said:

I would like to hear more about your journey

This is a small shop having fewer than fifty users. They have been running NetWare for the past twenty years. The NetWare servers hosted the NSS files, iPrint, GroupWise, and DHCP. There wasn't even an internal DNS. Network communications were using IP addresses and all workstations were members of a WORKGROUP. When I became involved I was tasked with a major infrastructure upgrade and it has been an interesting journey!

iPrint is now an appliance; NSS files, DHCP, and GroupWise are running on OES servers. CIFS is installed but the workstations are still using the Client for OES.

What I really wanted was the Windows workstations to be members of my domain so I could better manage my user accounts and be able to use such such features a Group Policy. We also needed to have Remote Desktop access to our Windows servers. To provide RDP access the Windows server, it had to be a member of a domain. 

When I began this journey the old GroupWise server still required eDirectory so DSfW seem to be an appropriate solution. I considered my requirements to be pretty basic and well within the capabilities of DSfW. Other shops using DSfW don't appear to be experiencing the same issues as I am so I am desperately trying to determine if my issues are due to DSfW limitations, bugs, or integrity issues with my servers.

I am not using and don't even have a Windows DC installed.

Exactly the same situation for me.  However I was able to successfully test RDS (Remote Desktop Services) running on a DSfW server without an actual Domain Controller installed.  There were a few client configurations changes needed, if you are using the OES Client, you don't need CIFS.

I've moved DHCP and DNS from OES to Ubuntu Server and we recently migrated from GroupWise to Microsoft 365.  We currently use FILR, but my hope is once I get approval for Windows Server Licensing, I can move to RDS.  I Implemented NAAF a few months ago to comply with our Cyber Insurance MFA requirements.

NAAF and DSfW do not allow synchronization with AzureAD accounts, iDM is needed for that.  My goal was to simplify my environment.

If you are running DSfW you should have all the machines Domain Joined, that may be part of the issue with running GPOs.  Some GPO's are computer policies and if the systems aren't part of the domain they will not run.  As a matter of fact, if any GPO as a computer element you will have a problem with the policy.

LDAP in AD and eDIr are little different and whether you say Novell Directory Services is closer to true LDAP or not, the industry standardized on Microsoft's Directory Services.  

I would suggest first joining one system to your DSfW domain and see if you still have the problems with the GPO, Applications and other things.