I'm running OES2 and DSFW. I have a virtual server farm with 66% Linux and 33% Windows 2008. DSFW is used to provide the necessary AD backend for some Windows services. All the Windows 2008 servers are part of a DSFW domain CDN.UCB.COM.AU

The main file server is an OES2 server. This is running CIFS (local eDir authentication) and workstation clients connect primarily using client32, but some are CIFS only.

Everything co-exists very well except for an application we are trying to install that run as a windows service. It is a CRM product (MPX) and it has a reporting function built into it. This reporting function has a reporting directory that is normally shared out. We want to store this directory on the main file server so that both the applicatiion and users can access it both using the application and from outside of it.

The problem is that when you install the application and specify the path for the reporting feature, the installation fails with an an authentication error. Looking at the log on the file server, we find that the server is trying to authenticate using the workstation name SVW-BNE-XEN-06$. While SVW-BNE-XEN-06 exists as a DSFW workstation object the '$' variation doesn't and so fails. Even if the name was correct, the password would change every 30 days or so as part of the Domain function so I believe.

The directory in question is totally accessible using any domain or eDir user from the WIndows 2008 server using either CIFS or the Novell client.

Can anyone suggest a solution? Can I have a Windows workstation authenticate to eDir? Can I force windows to install as a user instead of a workstation? Any other ideas?