I got a new Windows 7 32-bit machine (our only one) and I'm trying to get TAM to work on it. Homebase takes a long time to load each time you log in to TAM. The "loading homebase..." windows stays up for maybe three minutes then the cursor stays a revolving donut for as long as I have waited. After the "the loading homebase..." message goes away, and even though cursor stays donuted, you can begin to work in TAM as you normally would. Walked through with A.S. support: removing TAM and reinstalling; making sure config files were per A.S. specs; making sure that we were using the tamclient executable, etc.
Applied suggests maybe the mailbox was causing a problem but different user accounts and different small mailboxes do the same thing on this computer. They also recommended excluding the TAM files from our virus scanning which I'll try.
What files and/or directories do I need to exclude from my virus scanning? Anyone got any ideas on what else to try?
Thanks for the help.
Lance
Does Applied understand you are on version 10.4.
Executable path is different.. In Version 10.7 and up it points to client executable. Before this you would run x:\wintam\asupdate.exe /rr let TAM install client locally.
When done, it would still point to asupdate.. You would right click, properties, then target path and point to x:\wintam\wintam.exe
You also want to make sure your Windows Theme is set for Windows Classic.
It was trial and error learning experience to make TAM work in Windows 7 long before it was supported in 10.7 and up. You could always opt to upgrade to 10.7 or 10.8. Easy and quick update then instruction would apply. If you using 10.4, different instruction.
Hope you get resolved! :)
My bad Bob. Updating my sig now as we're on 10.7. Thanks for the effort.
Lance
Random thoughts.... Make sure that DNS settings are correct for the workstation, make sure that you install the .NetFix files from the Controls folder on your TAM share and maybe check config.NT and autoexec.NT (unlikely this would cause slowness). Make sure that all Windows and other third party programs are done updating. A lot of programs update in the background and give no indication that they are sucking the life out of your connection and computer. If the computer was just started, this would be a good bet. Check the task manager and sort by CPU load percentage. All I can think of for now.
any edits to Config.net and AutoExec.NT needed? I presume they are the same for Win 7 as XP.
Anything listed in Event Viewer that may give a better idea of what's happening?
+1 for Alice. Would be very helpful to get computer's viewpoint on what's going wrong. ;)
Quote from: Bob Connor on June 20, 2011, 05:54:37 PM
When done, it would still point to asupdate.. You would right click, properties, then target path and point to x:\wintam\wintam.exe
Hope you get resolved! :)
Just installed my first win 7 beast today (10.3) and my shortcut points to x:\wintam\homebase.exe and it works fine. Just sayin...
That different.. Never tried that. Real test is printing certain things.. If you left as is in earlier version had printer issues sometimes issues handing off to print spooler.. Changing to wintam.exe was shared as way to fix most print issues until Applied later supported. Most users just running asupdate and left alone, it worked too and not until certain print issued surfaced. Just unpredictable printing issues and wintam.exe as direct pointer resolved until 10.7 came out and now supported. :)
That does sound like an antivirus issue. You need to exclude the local Wintam directory, the mapped drives, and their corresponding UNC paths. I've also had to disable the "smart" antivirus features (in Kaspersky and AVG) to get TAM running smoothly.
For some reason, I noticed that some of the Windows 7 stations got "faster" after a couple hours of operation. I have a feeling that it had something to do with updates in the background, maybe disk indexing, or also .NET not being installed right away.
For some reason, I was able to run TAM without .NET installed, but it ran erratically and printing was very unpredictable. Some things would print, and others wouldn't print or would only print partially and print very slowly. Very strange, but it's all running well now.
Any changes in how it's running, Lance?
You will need to make sure that .NET Framework 1.1 is installed to fix various printing & display issues that surface (you can find it at G:\Wintam\Updates\Install\dotnetfx.exe).
The indexing of your computer on startup is a pain. You are slowing down every reboot to speed up searching your harddrive for something. How often are your users searching their computer for a file? They are having workflow issues if everything isn't already in TAM. But that is just my 2 cents.
Agreed, Ian. Thankfully, and unlike Windows XP, Windows 7's indexing only needs to do this once, then monitors changes in the background. XP's indexing is constantly grinding away in the background. That's whay you're probably hearing and experiencing when you hear the hard drive running, but don't see any CPU % times shown in Task Manager. I have turned off the indexing service on all of my XP machines because of this.
Installed TAM 10.7 on my laptop also for a second installation that I can test with. This second install does exactly the same thing. I disabled the virus scanner on both units but it doesn't help a bit. I believe that I already have the realtime scanners on the servers excluding the TAM directories but I need to make sure. Regardless of whether or not it is indeed an AV issue, Windows XP works fine and Windows 7 doesn't... I have no plan as of right now.
Lance
Almost forgot to post my fix....
Ended up being VERY simple on both machines. The windows 7 PC-path statement, under environment variables, system variables, was too long. When shortened, all was well. The first Applied technician simply missed this and the second one assumed that it had been checked off the list as a potential cause (as did I).
I was unable to get A.S. to pin down exactly how long the path variable can be - just that "when it gets to two lines, they start to see a problem". I took out of bunch of references to Roxio, Dell utilities, etc. and haven't found any issues yet.
Thanks for all the ideas.
All is well now.
I have always bumped up the Command.Com /E statement to 4096 in config.NT in order to avoid issues with document merges and the like. I don't know if the path statement would be affected by an environment size that was set too small or not, but I would suspect that it might. Might be worth bumping up just to make sure.