I put a message up a couple of weeks ago, about one of our sites who is trying to use Citrix Winframe to access our OI software. We have still not resolved this. Our remaining problem is that the Winframe users do not connect to the Netware NLM, preventing record locking. I have had a few replies on the forum, but have not yet got to the bottom of it.

The details are:

OI for Workgroups, v 3.61

Netware 4.0 server, using Revelation NLM

OI network driver: IPX v1.14 vxd.

Local clients: Win95

Winframe Clients: Windows NT 3.51 (this is what Winframe is bound to), using IPX protocol

Winframe Server using IPX/SPX transport protocol.

If we add a REVPARAM file to the revelation data directories, with the setting:

SERVERONLY=TRUE,

the Winframe clients cannot log in, proving they are not connecting to the NLM.

On the Winframe server:

OINSIGHT.INI in the WINDOWS directory.

OI DLLs in the WINDOWS\SYSTEM directory

NETWARE.DRV and VIPX.386 in the WINDOWS\SYSTEM directory

Winframe Server:P

Winframe Load Balancing is not implemented

The volume is formated with NTFS

The Winframe box is configured as a server, and not as a primary or backup domain controller.

There is another part of their set up which may be causing problems. Every workstation (including the Winframe server) connects to two servers:

1. A Novell Server, running the Revelation NLM. Our OI 3.6 app is stored on this file server. Accessed by IPX/SPX

2. A WinNT Server, which holds the user domains, and is used as a Mail Server. Accessed by TCP/IP

Is there any possibility of conflict here? It is difficult to check, as we currently need to connect to the NT Server to get the user domain info.

Any ideas?

Paul Rowe

Vernon Systems Ltd.

Paul,

I have a client that was unable to get their application to use the NLM via the Citrix clients. It appears to be some config /Security/access issue.

I was starting to wonder if the NLM and Citrix could work together at all, but now, having spent some time on site with the client, I think that the issues are related to netware/winframe configuration.

I made a site visit to a client that had not been able to get the winframe clients to load OI at all.

The setup is as follows.

Winframe server 1.60 service pack 5 installed.

OI for Workgroups, v 3.41

Netware 4.0 server, using Revelation NLM

OI network driver: IPX v1.14 vxd.

Local clients: Win95 WinNt and Win3.11

Winframe Clients: Windows NT 3.51 win95 WIN3.1 using IPX protocol

Winframe Server using IPX/SPX on using token ring with Ibm Token ring SNAP frame type.

I am unclear as to how this winframe server connects to the Netware server as the Gateway services admin utility indicated that the gateway was not enabled.The client said they were Using NDS and just mapped the drives on Login.

Initially, the client could get OI to Start but not see any LH tables ( including OI system tables) at all.

The Winframe server had drives C: thru T: mapped to novell server drives. THe Winframe boot drive was N: and the systemroot directory was called WINFRAME.

The Winframe servers WINFRAME\SYSTEM was missing the NETWARE.DRV, VIPX.386, NWCALLS.DLL and NWIPXSPX.DLL.

The OI LH driver was set to 1.14. ( Citrix patch applied )

The DLLS were copied in the WInframe\System directory .

The result was that we could now load OI and see the system tables but we were still unable to attach the applications data files.

We Tested the NLM access under AREV and determined that the NLM was

working with when using arev.

I then also noticed that it was version 1.5 of the NLM. So I changed the NET driver in OI to user the 1.5 version of the LH client.

(This version works can apparently tell the difference between a Citrix and Lan Client and use the appropriate method to acces the netware calls.).

With this change and the RevParam file set for Servonly=TRUE, we were now seeing the FFFFFF in the file handles under openinsight.

SO we were communicating with the NLM, we just couldnt access files in the applications data directories.

The Oinsight and Application data were store on the same drive P:

App Location: P:\OINSIGHT

Data location: P:\APPDATA

We were not able to attach any files in/under the APPDATA dir, even though the permissions/Novell rights/user groups were identical for both directories.

Since we had determined that the NLM was communicating with OI, We were able to get the client up and running by relocating the

P:\APPDATA directory within the OINSIGHT directory structure.

This then enabled the application to load and use the NLM for file access for both the Lan and Winframe CLients.

Neither Arev or OI were able to access the rev files stored in the other directory.I was able to delete files and add files via explorer ,the Dos command line and Basic plus Osb… functions etc.

Lan clients could access the data via the NLM in both locations.

It appears that for some reason when, requesting rev files from the

APPDATA directory, the credentials that winframe supplies don't qualify it for access for that directory.

I have been given a couple of explanations on how security works with winframe and as such I was also going to try using the REVELATION user model with the NLM.

If the NLM ignores the credentials provided by CITRIX, then it should provide the Citrix clients with the rev files, regardless of what credentials citrix supplies.

This is what i would try next.

Cheers Sam

[email protected]

The next thing I was going to try was creating the revelation user

and

Paul,

I have a similer setup using AREV 3.12 with Winframe 1.7

On the winframe server, your pif (or batch) must load the doskbd or tame to prevent keyboard polling in a multiuser environment and arevfix from Citrix before loading the TSR. You can also load the arevfix command in the autoexec.nt in the advanced pif properties.

I have a pif (that sets up the memory) that calls a .bat file:

doskbd /InProbationCount:3 /DetectProbationCount:3 /msSleep:500 /BusymsAllowed:250

t:\arev\lhipxtsr /p

t:\AREV\AREV.EXE , /X M4096

t:\arev\lhipxtsr /u

Email me directly for addtional information, hope this helps.

Chris Loope

View this thread on the forum...