NU Setup & Station Unlock - odd thing happening

[Alice]

I installed the 10.6 update over the Thanksgiving weekend and so far everything is working as it should.
I did notice something a bit odd recently that was not happening on 10.4, which I updated from. Please let me know if anyone has noticed this.

Part of my morning routine is to log in to Tam and change the date. I do a bunch of other things then set up Night Utilities. At that point, if I check Station Unlock, I see the login listed that I use for NU. I close Station Unlock. About an hour later I check Station Unlock again and that login is no longer listed and a different user now has that Machine number. Now, because I'm afraid NU will not run, after hours I cancel NU and set it up again so I can see it in Station Unlock.

Should I not worry about this? Does the NU login not require a user license?

[Andrew Carrick]

Did you get sorted on this one Alice? I've found NU does take a licence.

[Alice]

The only thing I can come up with is my first level support person testing something in Tam using the same login as the one used to set up/run NU. Then when she logs out of Tam, it deletes both locks.  The couple of times I've tested were inconsistent - sometimes both would disappear, sometimes just the one I used to log in to Tam.
I don't think I'm going to worry about it until it causes NU not to run. So far if NU is set up and I don't see a license used, it still runs. When it starts not running, I'll call Applied.

Not much help but that's all I gots   

[Alice]

I verified yesterday that no one used the login I use for NU and when I logged in last night, this is what I saw. NU ran fine with no errors. Never seen this before. Think I should report to Applied just so they have it?

[Andrew Carrick]

I guess the application continues to run without the station lock. Depends on how easy it is to get info from your Support people - after all it is working - but might be worth running past them?

[Alice]

Figured out something else.  When looking at Unlock and the NU login is Station zero, it drops later in the day as a license in use. If it's any other station number, it stays.
I reported to Applied.

[Alice]

okay...now Applied is involved and they cannot recreate on their side.  I love a good mystery!! We're doing some troubleshooting and I'll post what caused this and what fixed it if we figure it out.

[Mark]

Figured out something else.  When looking at Unlock and the NU login is Station zero, it drops later in the day as a license in use. If it's any other station number, it stays.
I reported to Applied.

Good sleuthing Alice!

[Alice]

Thanks Mark!  Although I feel like I'm talking to myself 
But the post has been read over a 100 times so I see some people are keeping an eye on it, and I will post the findings. Will be doing some testing Applied wants me to do after hours tonight, so we'll see.

Love this kind of stuff. That's why I liked being a beta tester.

[Alice]

What we've done so far and what we found is happening:

Applied sent me a new license file to rule out it being corrupt in any way. Last night replaced that file and deleted everything in the as_lock folder including the BG file.  Logged in to Tam to create new BG file & logged out. Set up NU to run at the normal 4am.

Note:  for the past 5 yrs or so we've been running NU directly on the server because NU would always fail/time out when run on a workstation because of network issues that were never fixed (and large files being packed/reindexed).  This is the first time we've ever had issues since running NU there.

The other thing I do every day, and this is where I discovered the problem since installing 10.6, is after I process the suspense items from my computer, I exit suspense before running the update and log in to Terminal Services to run the update there since it runs faster that way. Running the update on my PC could take 20-30 minutes – less than a minute at the server.
So...now we have NU logged in as user Backup and waiting on the Console and me logging in a TS session and Tam as myself. Looking at Tam Unlock, if NU has the zero machine slot and I log in to Tam in the TS session, my Tam login name is now the name at machine zero and nothing else has changed, except the time. The network, node address, session and BG range are the same as when Backup was logged in. If I log out of Tam and TS session, machine zero is removed from Unlock and user Backup is nowhere. At this point if another user logs in to Tam he/she can take the zero spot with unique network/node address.
I go to console and cancel NU. Set it up again and user Backup takes the next available slot, but now the user that has machine zero slot now says Stat File is missing, but user receives no errors and is using Tam without a hitch. If I cancel NU and wait about 5 minutes, Unlock shows machine zero as the user again.

So Applied has this now. They are going to try to set up as close to our environment as possible to see if they can recreate it. Don't know if they can since the Tam server OS is still Windows 2000. New server coming in next month and I should have it ready to go by the end of January/beginning of February.

[Alice]

Applied found the problem - they were able to recreate it. Let's see if I can explain this right.
We don't have Terminal Server licenses on the server. Apparently when I was using a TS client to login in, then log in to Tam, it was seeing me as being logged in as Tam and dropped the other login from Tam unlock. I'm not quite sure I understand it because it wasn't giving me the same machine number in unlock, I was assigned a different one. I was told to use Remote Desktop instead, which I will test over the weekend to see if it still happens...or not. They did admit that this does not happen with 10.4 but does with 10.6. Because there are no TS licenses, Applied is not going to pursue this as a problem.
I don't know what my network guy is going to do with the new sever I'm getting next month: still use Metaframe or use TS instead. Personally, I would like to get away from Metaframe altogether,mainly because of the continued printing issues, but it won't be my choice.

[DebAmstutz]

Glad the problem is no longer a mystery for you, at any rate.

[Bloody Jack Kidd]

If you use Citrix - you need both Terminal Server licenses AND Citrix licenses.  What version of Citrix are you on and what is the driving factor for using Citrix on top of Terminal Services?

also, what kind of printing issues do you have?

[Alice]

Metaframe Presentation Server. Not sure of the version. We have two Metaframe servers that several departments use. I just took a look and the terminal server licenses are on those severs. While Applied was on my insurance server, she showed me where it indicates TS is not "turned on" on that server. That's all I could find out by looking at the servers today. My network guy is the one who set up the servers and I was under the impression that the TS licenses were required on the Metaframe servers in order for them to work they way they should. I don't know if this is correct or not.

The main printing issue we have is receiving errors when someone tries to print a home application. We had this exact problem about 3 years ago when the Metaframe servers were load balanced and there were many printers auto created from those connected to individual PC's. At that time, because Applied could not resolve that issue, they recommended we not load balance and have the insurance users assigned to one server and everyone else assigned to the other. After we did that, no more printing issues with anything. So apparently there were auto created printers that were conflicting with Tam in some way and we left the server set up that way. Now we have the accounting department on the server with the insurance users and are having the same printing issue with the home app. Some accounting users have their own printers so I think it's the same issue as before. This is a recent development and I haven't had the time to see what printers are being auto created and to make sure the drivers were installed correctly or what drivers are actually installed. That's why in another post I asked if Applied had a list of supported printers. The user that reported the printing issue has yet to take the time to bring her laptop to IT to try and resolve. But there are more agents experiencing the problem because I can see the errors in the Except.log and they are no calling them in. This does not surprise me though.

[Bloody Jack Kidd]

hmmm...

there are several ways to control the creation of session printers (printers attached to client workstations), including disabling that feature altogether.  One of the nice features that Citrix has that makes it worth having over plain Terminal Services is the load balancing.  The issue you had may be due to the Citrix servers not being configured identically, or numerous other reasons.

But I've had citrix running here for years, load balanced and even with some session printing.  It can all work - even with printers not on Applied's A-list.  I don't think we've had supported printers for 7 years!