Local computer and Win domain password conflicts
If your computer is not domain joined and has a local account, these conditions will cause the login attempt to fail:
- The local account matches the user account name that you are using to establish the server connection and
- The passwords of the two accounts are different.
Therefore, a non-domain joined machine user who wants to access win.udel.edu 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 win.udel.edu. This problem has been seen on Mac and Windows computers.
Allowed connections/authorization errors
The error, Windows cannot access \\win.udel.edu\Root\Share, is often caused by devices using a connection other than a wired (Ethernet) connection or a eduroam Wi-Fi connection. 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 secure Wi-Fi (eduroam) connections, on-campus Ethernet connections, and connections through the UD VPN can connect to win.udel.edu 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 name 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:
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.