Frustrating Issue - Server 2008 R2/XP Clients..

[ProTech-MN]

I’ve been banging my head on this issue all last week and hoping someone has either seen something similar in the past or has some suggestions of what could be going on.

I recently installed a new Server 2008 R2 SP1 server for a customer (clean install – no migration from an existing 2003 server). There were zero issues, everything went smoothly. Server is configured as the sole server on the network running AD, DC, DNS, DHCP, IIS, and File/Print Services. It’s also running Symantec’s Endpoint Management Server along with SQL Server 2005 and a new LOB application that is not being used yet.

Hardware is a Dell T310 server with 12 GB RAM, running RAID 5 (3x500GB). NIC’s are dual onboard Broadcom BCM5716C Gigabit (Smart Load Balancing Team). Windows is fully patched & the firewall is disabled.

Clients are mixture of XP, Win2k, and NT4 (Yes, NT4!)….

The client is a machine shop and the issues they’ve been experiencing is opening/saving files from mapped drives on the server from within a couple of their CAD applications on their XP workstations. Copying/moving files from a command prompt or Windows Explorer is very fast – as is opening larger PDF’s or Office docs - it just seems to occur from within these CAD applications.

My first thought was the Antivirus software, but didn’t see any change after disabling the Antivirus software on the XP clients (even uninstalling – just to make sure). I also tried shutting down the Symantec services on the server. Next I figured it perhaps had something to do with SMB2 or a conflict between the XP clients and some of the advanced TCP settings in the 2008 tcp/ip stack so I tried disabling SMB2 (via the registry), disabling various TCP options: Chimney Offoad, LSO Offload, AutoTuning, RSS, etc. I’ve also tried disabling the NIC teaming and running just 1 NIC – all with no impact.

Mapping a drive and opening/saving the same files on their old Server 2003 server works perfectly…

Anyone have any ideas or suggestions?

TIA

Randy

 

[computerdoc]

Maybe the CAD software is using some sort of proprietary write technique that might be incompatible with something in the 2008 Server.

Can you contact the CAD software companies?

 

[Martyn]

What Cad software(and versions) are they running? Is the software running locally and the files stored on the server?

 

[ProTech-MN]

Surfcam and Machine Strategist are the apps - I don't have the specific versions in front of me here, but I think the version of Surfcam they're running is the 2004 version - Machine Strategist is at the latest version (5.1 I believe). They did see similar issues when they tried the latest version of Surfcam, but they can't run that in production due to some other issues/bugs within the software.

We did place a call to both vendors and neither had heard of the issue before, but were going to do some more checking...

The other issue they're seeing a performance issue is within Surfcam - post processing is very slow vs. almost instant when running against the Server 2003 files...


-Randy

 

[johnrobert]

Thats M$ for you things are supposed to get better not worse
go back to server 2003

 

[ProTech-MN]

Thats M$ for you things are supposed to get better not worse
go back to server 2003

LOL.. no doubt!

OK, so I did a couple of packet captures yesterday and noticed something interesting - when they run their post processing on a job in Surfcam, there are what appear to be a huge number of really small SMB reads (.130 is the workstation & .240 is the server):

49 10.273982   10.0.0.130            10.0.0.240            SMB      117    Read AndX Request, FID: 0x800f, 2 bytes at offset 0
50 10.274203   10.0.0.240            10.0.0.130            SMB      120    Read AndX Response, FID: 0x800f, 2 bytes
51 10.274296   10.0.0.130            10.0.0.240            SMB      117    Read AndX Request, FID: 0x800f, 2 bytes at offset 
52 10.274506   10.0.0.240            10.0.0.130            SMB      120    Read AndX Response, FID: 0x800f, 2 bytes
53 10.274590   10.0.0.130            10.0.0.240            SMB      117    Read AndX Request, FID: 0x800f, 1 byte at offset 4
54 10.274758   10.0.0.240            10.0.0.130            SMB      119    Read AndX Response, FID: 0x800f, 1 byte

When running the same job against the 2003 server or NAS reads the file in 4096 byte chunks..

Maybe it's SMB signing or encryption?

-Randy

 

[Martyn]

Actually reminds me of a problem I had a couple of years ago with server 2003. With smb, digitally signed packets are on by default and we had problems with our embedded xp controllers on our scanner not connecting. We had to turn digitally signed packets off on the server. It may have already been done on your 2003 server and you are getting the problem on the new server. I will see if I can find the fix.

I think this is it:

From Administrative Tools open Domain Controller Security Policy
Select \Security Settings\Local Policies\Security Options folder.
In the details pane, double-click Microsoft network server: Digitally sign
communications (always), and then click Disabled to prevent SMB packet
signing from being required.

Give it a try.

 

[ProTech-MN]

Actually reminds me of a problem I had a couple of years ago with server 2003. With smb, digitally signed packets are on by default and we had problems with our embedded xp controllers on our scanner not connecting. We had to turn digitally signed packets off on the server. It may have already been done on your 2003 server and you are getting the problem on the new server. I will see if I can find the fix.

I think this is it:

From Administrative Tools open Domain Controller Security Policy
Select \Security Settings\Local Policies\Security Options folder.
In the details pane, double-click Microsoft network server: Digitally sign
communications (always), and then click Disabled to prevent SMB packet
signing from being required.

Give it a try.

Thanks Martin - I gave it a try - no joy. Still dealing with this issue. I started a post on the MS partner forums and uploaded a few packet captures to them - their take on it is that the network layer is good & that the problem is at the application layer and suggested contacting the vendor (saw that one coming!)... of course, the application vendors are saying the same thing... (saw that one coming too!)

Continuing to try and figure this out...

-Randy