Win Domain File Services


Local computer and Win domain password conflicts

If your computer is not domain joined and has a local account, and the local account matches the user account name that you are trying to connect to the server with--but the passwords of the two accounts are different--the log on will fail.

Therefore, a non-domain joined machine user who wants to access must either have a local account that matches the domain account username AND password, or the local username being used not exist on the domain. This condition is true even if mapping a drive and selecting "Connect using different credentials." The best way to avoid this problem is to have users change local password to those used on This problem has been seen on Mac and Windows computers.

Allowed connections/authorization errors

The error, Windows cannot access \\\Root\Share, is often caused by connections through UDel wireless, not UDel secure wireless. If you are connected through wired and wireless adapters and see this error message, the computer is trying to connect to the share over your wireless adapter.

Only UDel secure wireless access, on-campus Ethernet connections, and connections through the VPN can connect to domain resources.

Offline files

Offline files are supported. However, you should be careful if this feature is used on more than one machine accessing the same file(s).

An example: A user has a desktop and a laptop. While either at home or traveling, offline files will be available as local cached copies of the documents on the laptop. That user accesses those files through either a mapped drive or a UNC while there is no authenticated connection to the server (i.e., they have Internet access but have not run the VPN). The file(s) appear to be on the server (i.e., show up in the mapped drive but in reality those files actually exist on the local machine). The user then saves the file(s) and exits.

Later, the user returns to the office, opens the file, makes edits, realizes the edits made while "offline" are not included, then saves the file. Now the user turns on the laptop, opens the file and sees changes and continues to edit the file on the laptop, and then saves the file again. All appears well on the laptop.

This step is where the conflict occurs. Now there are two files with the same name but different contents. One is located on the laptop BUT presented to the user as if it's on the server (i.e., the user will see the local file EVEN IF they type in the full path to the server).

That file will never upload to the server because there is a file on the server with a save date later than the last time the file was synchronized with the server. Anyone who accesses the file from any other machine will see the last synchronized copy. The only indication that there is a conflict will appear on the taskbar of the laptop as shown in the graphic below:

synchronization window

Clicking on the icon in the taskbar will bring up the Sync Center Conflicts control panel and allow the user to keep either the local file, the file stored on the server, or both.