TAM ON WIN10

[Ric]

Speaking of SMB1 and SMB2 we had dickens of a time attaching things to TAM last year and have had to resort to a unique and "unsupported" setup.

Users were getting "Reading bytes from file" dialog/message while attaching an Email etc. to TAM - it would take anywhere from 2-5 minutes then would clear and they could move on.  Worked with a savvy tech at Applied who found we had SMB2 turned on (Regedit on the Windows 2012R2 server = SMB2=1)

We were instructed to turn off SMB2 (SMB2=0) which we did.  No reboot of the server was required (although the tech asked us to do so)

Yay!  This solved the attaching problem instantanly.

The next day our accounting person is in agony over how long it was taking to do "simple" accounting things such as look up a disbursement and other Accounting functions.  it was taking minutes where it had been taking 30 or so seconds.

Putting 1 + 1 together and getting 3, I tried an outside the box idea and turned on SMB2 for our Accounting person, had her reboot and LO and BEHOLD disbursements and other functions were back to their normal / tolerable speed.

We quickly found that any regular (CSR, producer, etc.) workstation that was rebooted reverted to watching the paint dry when attaching things to TAM.

Therefore, since then we have been running with SMB2 off and anytime the accounting person reboots her machine, I turn SMB2 back on while she reboots and logs in, then I turn it back off.

Fun, huh?

Such is the world in which we live.

[Hans Manhave]

Ugh!  How sad.

Speaking of SMB1 and SMB2 we had dickens of a time attaching things to TAM last year and have had to resort to a unique and "unsupported" setup.

Users were getting "Reading bytes from file" dialog/message while attaching an Email etc. to TAM - it would take anywhere from 2-5 minutes then would clear and they could move on.  Worked with a savvy tech at Applied who found we had SMB2 turned on (Regedit on the Windows 2012R2 server = SMB2=1)

We were instructed to turn off SMB2 (SMB2=0) which we did.  No reboot of the server was required (although the tech asked us to do so)

Yay!  This solved the attaching problem instantanly.

The next day our accounting person is in agony over how long it was taking to do "simple" accounting things such as look up a disbursement and other Accounting functions.  it was taking minutes where it had been taking 30 or so seconds.

Putting 1 + 1 together and getting 3, I tried an outside the box idea and turned on SMB2 for our Accounting person, had her reboot and LO and BEHOLD disbursements and other functions were back to their normal / tolerable speed.

We quickly found that any regular (CSR, producer, etc.) workstation that was rebooted reverted to watching the paint dry when attaching things to TAM.

Therefore, since then we have been running with SMB2 off and anytime the accounting person reboots her machine, I turn SMB2 back on while she reboots and logs in, then I turn it back off.

Fun, huh?

Such is the world in which we live.

[Jeff Golas]

Speaking of SMB1 and SMB2 we had dickens of a time attaching things to TAM last year and have had to resort to a unique and "unsupported" setup.

Users were getting "Reading bytes from file" dialog/message while attaching an Email etc. to TAM - it would take anywhere from 2-5 minutes then would clear and they could move on.  Worked with a savvy tech at Applied who found we had SMB2 turned on (Regedit on the Windows 2012R2 server = SMB2=1)

We were instructed to turn off SMB2 (SMB2=0) which we did.  No reboot of the server was required (although the tech asked us to do so)

Yay!  This solved the attaching problem instantanly.

The next day our accounting person is in agony over how long it was taking to do "simple" accounting things such as look up a disbursement and other Accounting functions.  it was taking minutes where it had been taking 30 or so seconds.

Putting 1 + 1 together and getting 3, I tried an outside the box idea and turned on SMB2 for our Accounting person, had her reboot and LO and BEHOLD disbursements and other functions were back to their normal / tolerable speed.

We quickly found that any regular (CSR, producer, etc.) workstation that was rebooted reverted to watching the paint dry when attaching things to TAM.

Therefore, since then we have been running with SMB2 off and anytime the accounting person reboots her machine, I turn SMB2 back on while she reboots and logs in, then I turn it back off.

Fun, huh?

Such is the world in which we live.

I'd be wiling to bet there's a naming problem here...naming as in DNS/WINS/NETBIOS, potentially all of the above fighting. THey're all sort of on by default, but really you only need one naming system, and DNS is the way to go. WINS and netbios should be disabled it not done already, and you may have to look at some DNS and/or DHCP settings to see how things are cookin. These kinds of issues forced me to learn this stuff in better detail.

I'd be willing to bet if you do an nslookup of your file server from an affected workstation, it'll prob be routing elsewhere or not resolving properly. You should be able to nslookup the server name itself without the fqdn (server vs server.domain.net), as well as using the full fqdn (server.domain.net).

In addition, I'd be pushing a GPO to disable smb1/2 if necessary. SMB3 is the way to go and SMB1 should be disabled everywhere.

[Ric]

Speaking of SMB1 and SMB2 we had dickens of a time attaching things to TAM last year and have had to resort to a unique and "unsupported" setup.

Users were getting "Reading bytes from file" dialog/message while attaching an Email etc. to TAM - it would take anywhere from 2-5 minutes then would clear and they could move on.  Worked with a savvy tech at Applied who found we had SMB2 turned on (Regedit on the Windows 2012R2 server = SMB2=1)

We were instructed to turn off SMB2 (SMB2=0) which we did.  No reboot of the server was required (although the tech asked us to do so)

Yay!  This solved the attaching problem instantanly.

The next day our accounting person is in agony over how long it was taking to do "simple" accounting things such as look up a disbursement and other Accounting functions.  it was taking minutes where it had been taking 30 or so seconds.

Putting 1 + 1 together and getting 3, I tried an outside the box idea and turned on SMB2 for our Accounting person, had her reboot and LO and BEHOLD disbursements and other functions were back to their normal / tolerable speed.

We quickly found that any regular (CSR, producer, etc.) workstation that was rebooted reverted to watching the paint dry when attaching things to TAM.

Therefore, since then we have been running with SMB2 off and anytime the accounting person reboots her machine, I turn SMB2 back on while she reboots and logs in, then I turn it back off.

Fun, huh?

Such is the world in which we live.

I'd be wiling to bet there's a naming problem here...naming as in DNS/WINS/NETBIOS, potentially all of the above fighting. THey're all sort of on by default, but really you only need one naming system, and DNS is the way to go. WINS and netbios should be disabled it not done already, and you may have to look at some DNS and/or DHCP settings to see how things are cookin. These kinds of issues forced me to learn this stuff in better detail.

I'd be willing to bet if you do an nslookup of your file server from an affected workstation, it'll prob be routing elsewhere or not resolving properly. You should be able to nslookup the server name itself without the fqdn (server vs server.domain.net), as well as using the full fqdn (server.domain.net).

In addition, I'd be pushing a GPO to disable smb1/2 if necessary. SMB3 is the way to go and SMB1 should be disabled everywhere.

Thanx Jeff!

Looking into this...

[Jeff Zylstra]

I went through this years ago with opportunistic file locking, so I feel your pain. 

I thought this was a good article on the various versions of SMB and what they do, and how to manipulate them.  Good luck and let us know how you come out!

https://docs.microsoft.com/en-us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3

[Hans Manhave]

Turning off SMB2/3 apparently does not relieve the problem.  The user just got used to the station disconnecting from TAM after some time away from her desk and didn't let me know anymore.      I did notice that our Dell 5548 switch likes to reset the "green" setting if power to it is lost.  So I, again, turned that off.  No idea why that switch resets just that feature.  There is no battery inside.  UPS does hold during power outages and the generator kicks on within a minute when needed.  I just watch the switch clock setting more often now because that also resets.  The uptime of the switch has become interesting.  For reference, other work stations (pre-Win10) have been on that cubicle and switch port without a problem.  Considering trying the station wireless, just to see what that will do.

[Hans Manhave]

Further info, in case someone wants to attack this:

Looking through the event log, there are continuous PNRPSvc 102 errors.  This appears to apply to a Windows Server 2008R2 which we have.  I just have not found something that resolves this.  Also found a bunch of "Bonjour" activity.  I have yet to locate a solution for this.  Windows 10 workstation.

[Jeff Golas]

Bonjour is a discovery protocol thats usually used by Apple Devices, like ipads/iphones, especially for printing, so even if you don't have Apple devices, it can be coming from a printer.

Not sure what the other is (yet) but curious. I have a meeting all afternoon so I can't play Google today.

[Hans Manhave]

Finally, after four years or more.  Found the teeny little tick box to undo.  It was known to be a TAM activity thing, but where and how? 

Tools, user setup options, settings, timer setup, update open activity = uncheck this (or possibly give it some huge interval that I don't care to try out).

This does appear to get TAM2014 to not error out constantly on Windows10 (and Win2K8R2 server).

I may have to revisit this, but so far it has continued to work.  I guess if one's day depends on open activities, this may not be a great solution.

Yet one more issue.  Possibly a network interface problem?  "Could not read at least 8 bytes at offset 0 in "G:\TAM\TFILE_W.NDX": Error 59: An unexpected network error occurred.

The card does not go to sleep, neither does the computer, no screen saver.  I set the network card speed to 1Gb up/down instead of "auto". 

Anything else to adjust?  I have no idea yet if the above has now fixed it.  It seems to happen when the user is away from the terminal.