Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pwright]

I have 2 versions loaded on a Citrix Server 5.1.26 & 5.0.67.  5.1.26 is under C:\Program Files\J River & 5.0.67 is under F:\Program Files\J River.  When the 5.1.26 ICElp is launched it creates C:\Winnt\icetcp.ini and that will not work since I have multiple users on this machine that connect via Citrix Sessions.  When 5.0.67 is launched, it creates C:\Documents and Settings\username\WINDOWS\icetcp.ini.  That is what we want so each remote site can have its own icetcp.ini file.  However when the ICElp 5.0.67 is launched, it looks for something that it cannot find.  I thought the newer version would potentially fix whatever the problem was with 5.0.67 so that is why we tried downloading and installing that.  But 5.1.26 does not appear to allow us to setup individual ini files as 5.0.67 did - only C:\Winnt, which in that case, I can only have 3 remote sites using ICElp which does not really help at all!  Any thoughts anyone???

[jimn]

I looked at the actual source code of ICElp in versions 67 & 1.26; there is no difference between the versions relevant to this issue. Both use a function called GetWindowsDirectory to get the path for icetcp.ini.

Under the documentation for GetWindowsDirectory, I found the following:
Terminal Services:  If the application is running in a Terminal Services environment, each user has a unique Windows directory. If an application that is not Terminal-Services-aware calls this function, it retrieves the path of the Windows directory on the client, not the Windows directory on the server.


My guess is your version 0.67 iICELp is "Terminal-Services-aware" and your 1.26 is not.  I'm not very familiar with TS, but I'm guessing this means your Terminal Services has only one registered. Or, if both of them are registered, perhaps TS can't work with two different copies of the same program (ICElp.exe), and is ignoring the second one.  ...just a theory.

JimN

P.S. The newer version can store certain pathnames internally in a larger buffer, so long pathnames don't get cut off. This could account for the error you are getting in the older version. However, as I said, this has no bearing on where the program puts the INI file.

[pwright]

"My guess is your version 0.67 iICELp is "Terminal-Services-aware" and your 1.26 is not.  I'm not very familiar with TS, but I'm guessing this means your Terminal Services has only one registered. Or, if both of them are registered, perhaps TS can't work with two different copies of the same program (ICElp.exe), and is ignoring the second one.  ...just a theory."

I would agree with your statement above that .67 was TS Aware and that 1.26 is not.  My client was told this was a Citrix problem, but I would believe from what I see happening this is a James River problem.  Is there any solution you can see as to how we can make this work for them.  They have not been able to print effectively now for about 3 weeks.  I would prefer to only have 1 version of ICE.TCP Pro & ICElp loaded on this machine, the only reason we loaded both was to see that .67 did create the file under C:\Documents and Settings\Username\WINDOWS\icetcp.ini and that 1.26 only loaded under C:\WINNT

Thanks!
Paul

[Bob]

"My guess is your version 0.67 iICELp is "Terminal-Services-aware" and your 1.26 is not.  I'm not very familiar with TS, but I'm guessing this means your Terminal Services has only one registered. Or, if both of them are registered, perhaps TS can't work with two different copies of the same program (ICElp.exe), and is ignoring the second one.  ...just a theory."

I would agree with your statement above that .67 was TS Aware and that 1.26 is not.  My client was told this was a Citrix problem, but I would believe from what I see happening this is a James River problem.  Is there any solution you can see as to how we can make this work for them.  They have not been able to print effectively now for about 3 weeks.  I would prefer to only have 1 version of ICE.TCP Pro & ICElp loaded on this machine, the only reason we loaded both was to see that .67 did create the file under C:\Documents and Settings\Username\WINDOWS\icetcp.ini and that 1.26 only loaded under C:\WINNT

Thanks!
Paul

Actually what Jim is saying is that the problem is NOT related to IceLP. He said:

"I looked at the actual source code of ICElp in versions 67 & 1.26; there is no difference between the versions relevant to this issue. Both use a function called GetWindowsDirectory to get the path for icetcp.ini."

This means that the code that is accessing the ini file is the same. There are no functions of .67 vs .126 that are "citrix/ts" aware as far as IceLP is concerned.

What I believe he is saying is that there is something different about the way IceLP is installed on the terminal server machine that makes terminal server/citrix aware that it has to do something about that mapping of the windows directory. Since the call to GetWindowsDirectory is the same in both versions, it's NOT IceLP that is doing that mapping.

[jimn]

I would agree with your statement above that .67 was TS Aware and that 1.26 is not.  My client was told this was a Citrix problem, but I would believe from what I see happening this is a James River problem.  Is there any solution you can see as to how we can make this work for them.

What happens when you remove, or at least unregister the 0.67 ICELp and register the 1.26 ICELp?

My guess is that this would solve the both problems.

JimN

[pwright]

We did remove the older version.  The only reason we added it back was so that my client who is on-site could show me that the older version .67 installs into the individuals ini file and the 1.26 does not.  The 1.26 loads C:\WINNT\icetcp.ini everytime.  The .67 in the past loaded to each individuals own Windows Directory and created the icetcp.ini there.  What would your suggestion be that I try at this point?  Thanks!!!

[jimn]

Did you register the 1.26 version of ICELp in Terminal Services?

My knowledge of Terminal Servers are very limited. If this doesn't work, I can't think of what else to try.
JimN

[pwright]

Is there any way that ICElp can be improved to allow more than 3 PC Printers queues to be setup?  That way my Terminal Server could be running ICElp and have all my remote sites setup in it.  I don't know if you could make it unlimited, but having 25 to 50 would allow my client to set up all their remote sites this way and hopefully be able to print again.

Thanks! 
Paul

[jimn]

That would be a nice enhancement, and we will keep that in consideration, however, for the time being, the limit for ICElp will be 3 printers.

JimN

[Bob]

You could also run ICELP on the remotes directly through your VPN tunnel to the Unix machine instead of using the terminal server as an intermediate stop.

[pwright]

Unfortunately they do not have VPN Tunnels at their remote sites back to the Main Site.  I recommended this a while back, but they do not have VPN routers.  Their connection to the server would be no different than you or me trying to connect to their Terminal Server and then needing to print to your local printer.  I sent Deanna an E-mail 5/9/07 and then forwarded that again today, if that is a possibility just let me know.

Thanks!
Paul

[Bob]

Paul,
They are connecting directly to the terminal services like they are on a lan (not using that funky web based interface to terminal services)? What is the security if there is no vpn? Are they firewalling by IP?

If they are using static addresses and a firewall then it would be even easier to put icelp on the remotes. In the meantime we'll have a discussion about your email...

Bob

[pwright]

I don't know why I did not think of this sooner, I just sent you an E-mail too, I will open port 2346 to point to their Unix Server and then ICElp can run at the remote sites.  As far as I know, none of the remote computers have ICE.TCP Pro loaded on them, it is just on the Main Server.  What would be the best way to load just the ICElp or ICE.TCP Pro on the outlying Windows PC's - they have the Unlimited Terminal Server version of ICE.TCP Pro.

Thanks!
Paul

[Bob]

Purchase the update, run setup and cancel out when it gets to the configwizard part.

It would be best for the remotes to have static IP's and firewall out access to 2346 to unauthorized hosts.