Doper Server/Network gurus....I got a stumper

[drachillix]

relevant email between me and scanner/copier/company

in reply to a delay in scans dropping to a shared folder on a windows 2011 server from copier.

The scanner logs into the server and drops a scan job to a shared folder. The workstations have a shortcut to the same network folder and allows them to access the document.

[COLOR=#000000][FONT=Times New Roman]

[SIZE=3][COLOR=#000000][FONT=Times New Roman]I already talked to NEC about this issue. The machine is doing its job. It has no control over the network over speed. NEC’s words. If it’s getting there something in the network holding it up. My best suggestion is to go directly to the workstation Bypassing the server. Or better yet, connect a lap top directly to the NEC and see if you have the same problem, if you do I can take that directly to NEC.

[/FONT][/COLOR][/SIZE]

my reply

[/FONT][/COLOR]
Scanning is the issue I am having the most trouble with.

Scanning jobs are getting held up and not transferring to the server promptly. The client workstation is not part of the transaction except that it views the same shared folder that the server drops it to. I have been able to replicate the problem and the scans do not get there for at best several minutes. As the issue seems to be transient it is making it a royal pain to diagnose a specific cause.

The last scenario I tested when problem manifested.

Scanned
walked to customers workstation ..no scan in folder
walked to server…logged in, accessed scanner share folder.. no scan.
walked back to copier, scanned again
walked to customers workstation ..no scan in folder
walked to server… accessed scanner share folder.. no scan, refreshed and sorted by date/time to verify I was looking at newest files.. no scan.
walked back to copier, scanned again
walked to server…logged in, accessed scanner share folder.. 3 new scans all showed the same time and date stamp. The server received all 3 at the same time.
walked back to copier, scanned again
walked to server…logged in, accessed scanner share folder 1 new scan showed in share.
repeated tests after that all went through immediately with no delay.

ETA: At several of the above steps I puttered for a minute to see if it would “show up”

Next day, customer experiences similar delays.

The server is a 3.6ghz 4 core processor with 16GB of RAM, the server is not experiencing any significant load that would account for any delay. Definitely not 3-5 minutes.
There is no driver to contend with on a scan as its dropping to a share, a driverless process.

The customers workstation is not part of the transaction at this point.

There are no other such delays in network share based tasks that I am aware of.

Ed is the only person who seems to be having this issue, but since his machine is not part of a scanner transaction, there is no way for it to be anything to do with his workstation.

No other users all using the same copier and server have expressed a problem.

See where this looks puzzling from my end. I’m not trying to start a finger pointing session. I want to find a solution. From my end, and the servers own time and date stamps, it looks like the copier is not sending them. I also admit I have no knowledge of the inner workings of the copier to understand where such a delay may take place to “blame the copier”. I do know the inner workings of the server however and the idea that a 2-3 megabyte scan job would be bogging in the server for 3-5 minutes would be kinda like insisting a pea can plug a fire hose. Also until a couple weeks ago the scanning was working fine. Eds machine was replaced near that time frame, but since his machine is not involved in the file transfer between the scanner and the server, it can be safely excluded as the cause of the problem.

[Askance]

How exactly are you determining from the workstation that the file is or is not there in the shared folder? Are you manually refreshing Windows Explorer or what?

One possibility that occurs to me is the anti-virus apps on servers and/or workstation.

If you log onto his machine as someone else, or even admin, are the same delays seen?

[drachillix]

@Askance

How exactly are you determining from the workstation that the file is or is not there in the shared folder? Are you manually refreshing Windows Explorer or what?

Yes, the workstation is accessing a shared folder on the server, same folder the scanner drops it in. I actually went over to the server and checked there…files are not in the server either. so the problem is happening somewhere between the copier/scanner and the server. The copier company is defaulting to, “must be the server”.

One possibility that occurs to me is the anti-virus apps on servers and/or workstation.

I actually tried uninstalling it and letting the server run without for several days just to see if it made a difference.

If you log onto his machine as someone else, or even admin, are the same delays seen?

Scanning is triggered at the copier, which transfers the file to a shared folder on the server, the workstation has a shortcut on the desktop to access the folder to retrieve scanned files.

at no point is the scanned file actually moved to the workstation unless the user moves/copies it to the workstation.

[J_Cubed]

Try logging into the server using the same credentials as the scanner. Is it as fast as a regular user? Try turning off Ed’s workstation and scanning. Is his machine locking the directory? Is there any diagnostic output or configuration settings you can access? Does it matter if you scan a picture vs a text document?

[si_blakely]

Your best place to start is with a copy of Wireshark, and monitor the network traffic on the scanner/server segment as the scan/copy proceeds. You will be able to see the protocol actions as they occur, spot connection failures/retries and and packet collisions that could slow down the transaction. Using this will tell you if the delay is on the printer/scanner or on the network transfer.

Also, what is the security protocol for this process - usually there is some sort of passcode action at the scanner to restrict access to the user who made the scan or identify the file on the share. There may be some setting associated with the users passcode that triggers an action on the scanner that slows up delivery (compression level, etc).

[Phishin_CA]

How are the UNC paths set up on the machine? By ip, or host name? If it is by host name, check the dns server the copier is using. If it is your local dns, make sure that the copier can query it.

I would definitely fire up wireshark as well

[Mangetout]

It sounds to me like the scanned image is taking a while to actually start leaving the copier/scanner - maybe it caches it on a hard drive and there’s something wrong with that device? (insufficient free space due to junk files from previous aborted jobs or something)

Or it’s taking time to prepare the file for depositing on the share - what format is it delivering the images in? If it’s something like PDF or .doc, it might be that it just takes a while to render in that format.

[drachillix]

@J_Cubed

Try logging into the server using the same credentials as the scanner. Is it as fast as a regular user? Try turning off Ed’s workstation and scanning. Is his machine locking the directory? Is there any diagnostic output or configuration settings you can access? Does it matter if you scan a picture vs a text document?

I created an admin account just for the scanner, the scanner logs into the share with that account no matter who scans.

The user puts document on scanner, selects who its for on touchscreen, and pressed start. The login and pathing are all preset on the copier, the user does not need a pwd, it is routed to the proper folder based on who was selected on touchscreen.

[drachillix]

@si_blakely

Your best place to start is with a copy of Wireshark, and monitor the network traffic on the scanner/server segment as the scan/copy proceeds. You will be able to see the protocol actions as they occur, spot connection failures/retries and and packet collisions that could slow down the transaction. Using this will tell you if the delay is on the printer/scanner or on the network.

Had not thought of wireshark, thank you, I will definitely try this.

[drachillix]

@Mangetout

It sounds to me like the scanned image is taking a while to actually start leaving the copier/scanner - maybe it caches it on a hard drive and there’s something wrong with that device? (insufficient free space due to junk files from previous aborted jobs or something)

Or it’s taking time to prepare the file for depositing on the share - what format is it delivering the images in? If it’s something like PDF or .doc, it might be that it just takes a while to render in that format.

Its pdf

The Guy loves printing 20 page pdf files @ 11x17…so its no shock if it takes a min to spool that (part of why the print queues are on the server so his workstation does not choke on them)

One of my suggestions to the copier company was to “hard reset” the copier and wipe out all the settings and I would recreate the needed user paths, they disagreed that this would be helpful.

[Mangetout]

@drachillix

Its pdf

Ah - I would strongly suspect that as the bottleneck. Are there any settings on the copier pertaining to the quality/compression for the PDF?

One of my suggestions to the copier company was to “hard reset” the copier and wipe out all the settings and I would recreate the needed user paths, they disagreed that this would be helpful.

I’d have given that a try too. If it’s your own (as opposed to a managed lease) machine, and you’re confident you can restore all the other settings afterwards, I’d try this anyway.

Also, does the copier have any kind of ‘clear cache’ functions?

[Quartz]

Given you say Server 2011, I assume it’s SBS 2011, right? Next, you say that no one else has said they have a problem: have you tested it? Try using the exact same document. Next, have you checked the event logs? Check both the server and the copier. How does the copier authenticate against the server? Does it use its own credentials or the user’s?

BTW if they have a mail server, you might consider having the copier email the scanned document - useful for confidentiality.

[si_blakely]

@drachillix

The user puts document on scanner, selects who its for on touchscreen, and pressed start. The login and pathing are all preset on the copier, the user does not need a pwd, it is routed to the proper folder based on who was selected on touchscreen.

As I noted above, since each user appears to have their own profile on the printer, it might be worth checking the problematic users profile to see if there is anything different about it. Or just delete that profile and recreate.

[drachillix]

@Mangetout

Ah - I would strongly suspect that as the bottleneck. Are there any settings on the copier pertaining to the quality/compression for the PDF?

I’d have given that a try too. If it’s your own (as opposed to a managed lease) machine, and you’re confident you can restore all the other settings afterwards, I’d try this anyway.

Also, does the copier have any kind of ‘clear cache’ functions?

Copier is a lease unit.

[TroutMan]

Do you have Offline files enabled somewhere in the mix? I saw a similar issue where users weren’t always seeing files on a network share in real time and the offline files synchronization was the culprit.

[md2000]

Simple thing I think of when the network appears to be sloooooow or erratic - is the copier running half duplex and the switch full duplex (or vice versa?).

If one end thinks it can talk while it is also receiving, and the other end thinks of that as a collision, then the half-duplex end will get very frequent collisions and stop-resend the packets. On a large file, that could slow the network connection for that device to a crawl.

It’s possible the “auto-negotiate” for speed and duplex is faulty on the copier; or someone has hard coded the switch to the wrong setting? (If it’s negtiating 10Mbps for a very large file, that also might do it.

[Suburban_Plankton]

@md2000

Simple thing I think of when the network appears to be sloooooow or erratic - is the copier running half duplex and the switch full duplex (or vice versa?).

If one end thinks it can talk while it is also receiving, and the other end thinks of that as a collision, then the half-duplex end will get very frequent collisions and stop-resend the packets. On a large file, that could slow the network connection for that device to a crawl.

It’s possible the “auto-negotiate” for speed and duplex is faulty on the copier; or someone has hard coded the switch to the wrong setting? (If it’s negtiating 10Mbps for a very large file, that also might do it.

In my experience, this is more often than not the culprit in the case of “inexplicably slow network speeds”. The simple fix for the issue is to never use auto-negotiate on your switch or your NICs. Pick a speed/duplex combination that works and hard-code it on every device.

[si_blakely]

@Suburban_Plankton

In my experience, this is more often than not the culprit in the case of “inexplicably slow network speeds”. The simple fix for the issue is to never use auto-negotiate on your switch or your NICs. Pick a speed/duplex combination that works and hard-code it on every device.

While I would generally agree, the OP indicates that this is only an issue for one user out of many. An autonegotiation fault would impact all users equally.