Scan to SMB Share Broke After Migration to NetApp Filer

[Soggy]

We have several different Bizhub multifunction devices at medical facilities throughout the country. They all are setup to scan medical records to a file server that was originally living on an EMC Celerra NAS. Everything was working fine until we migrated the file server to our new NetApp filer. We also have some Ricoh and Kyocera devices at different locations and they continued to work after the migration. All of the devices use the same AD credentials to authenticate so we know that this is not a permissions issue. We've also tested access to the share manually from a workstation and it works fine. I'm not at the site where the copiers are, but I'm told the error is a rather vague 'unable to connect to server' type error. The NetApp sees the copier try and authenticate and passes the login credentials to AD, but AD rejects the logins. The credentials that get passed from the device to the NetApp appear to be messed up. For example, this is from the logs on the NetApp. It's passing the 'WORKGROUP' field name as the domain name rather than what we have entered in that field on the device. We have the real domain name entered in the 'workgroup' filed on the device.

Login attempt by domain user 'WORKGROUP\svc-5800Scan-LTPAC' using NTLMv2 style security

I'm just wondering is anyone out there has run into anything like this.

[allan]

If you go to the job log and details you would get an error code you can reference against the network trouble shooting code list in the machines manual.

[wseyller]

Just to confirm you do have the domain listed in the administrator settings then Network then IPV4 settings then DNS Domain settings on the copier?

Also how is the username configured in the address entry. Is it just <username> or <domain/username>

[emujo]

That "workgroup" domain name is coming from the MFP. The older file storage system may have allowed it, but the new system may need the domain name changed under ADMIN/NETWORK/SMB/Client settings. If the new drive is "mapped" the MFP may fail to see it without a true UNC path. If you attach the domain name to the user name you may get a login attempt using both domains which would also fail. And yes, the error message is very vague, but with the new e series MFPs you can at least do some basic trouble shooting from the control panel by verifying a good connection to the host you wish to scan to. IMO best practices is to work from the MFP back when setting up one touch smb scans. This way you can verify the UNC path, username and password to be correct. I would also look at utilizing scan to me and scan to home since you are already working with AD. Emujo

[Soggy]

Just to confirm you do have the domain listed in the administrator settings then Network then IPV4 settings then DNS Domain settings on the copier?

Also how is the username configured in the address entry. Is it just <username> or <domain/username>

Thanks for your response. Just so everyone knows what my role is in all of this, I'm the guy who migrated our clients file server from EMC to NetApp. Because this 'broke' their scan to folder, I've been trying to fix this for them. Also, the MFP's are on the other side of the country so it's difficult to test different settings. I can make the changes through the web interface, but I don't have direct access to the end users so I can't get someone to initiate a test scan.

Anyway, regarding your question, I assume you mean the field that is labelled 'DNS Default Domain Name'? It currently is NOT set to the Active Directory domain used for user authentication, but rather to our clients own DNS domain. Because you asked, I assume this field should have the Active Directory domain in it for this to work properly?

As for the username, I'm guessing you are referring to the 'User ID' field in the Store Address book page for the scan to folder entry. The tests I've been able to try have had it set to just 'username'. I think someone also tried 'username@ad-domain.com'.

[Soggy]

That "workgroup" domain name is coming from the MFP. The older file storage system may have allowed it, but the new system may need the domain name changed under ADMIN/NETWORK/SMB/Client settings. If the new drive is "mapped" the MFP may fail to see it without a true UNC path. If you attach the domain name to the user name you may get a login attempt using both domains which would also fail. And yes, the error message is very vague, but with the new e series MFPs you can at least do some basic trouble shooting from the control panel by verifying a good connection to the host you wish to scan to. IMO best practices is to work from the MFP back when setting up one touch smb scans. This way you can verify the UNC path, username and password to be correct. I would also look at utilizing scan to me and scan to home since you are already working with AD. Emujo

Thanks emujo... there is a field called 'Workgroup' under Admin>Network>SMB Setting>Print Setting. We have the AD domain name entered in that field. Is this correct? If so, do we enter the NetBIOS domain name (i.e. 'ADDOMAIN') or do we use the fully qualified domain name (i.e. 'ADDOMAIN.COM') or doesn't it matter? The path to the share is a true UNC path. We've tested access to the share from a workstation onsite using the credentials assigned to the MFP so we know the file server is working properly. They are using the scan to email as a workaround right now. Thanks!

[emujo]

you don't need the .XXX, also try changing to NTLM V1/V2 under the client settings. Emujo