This kb lists issues with connecting to and using Azure backed Win Domain File Services.
Login failure dues to 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 have either a local account AND password that match the user's domain account, or the local username must not exist on the domain. This condition is true even when mapping a drive and selecting "Connect using different credentials." The best way to avoid this problem is to have users change local passwords to those used on the win.udel.edu domain. 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 an 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 (off-campus) can connect to win.udel.edu domain resources.
Offline files
Offline files are supported. However, be careful if you use this feature on more than one machine that accesses the same file(s).
Example situation: A user has a desktop and a laptop. While either at home or traveling, offline files are 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 (for example, they have Internet access but have not connected to the VPN). The file(s) appear to be on the server (in other words, they show up in the mapped drive but in reality those files actually exist on the local machine). The user works on a file, then saves that file and exits.
Later, the user returns to the office, opens the file, makes edits, realizes the edits made while "offline" are not included, and then saves the file. Then 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 that 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.