Microsoft Network Client: Digitally Sign Communications (Always) = Disabled.Computer Config\Windows Settings\Security Settings\Security Options:. We only loosened these policies on the backup server, and the workstations being backed up at "slow link" sites, as these were the only systems needing to access the respective shares: And second, we had to "loosen" two policies that DISA normally recommends for most domain members. First, we created static DNS entries on the DNS servers to allow for proper name resolution. To enable the UNC shares as configured, we had to set up two main things. These particular Drobos do not have the ability to participate in the AD domain. So we placed Drobo NAS units on each local segment to overcome this and give us a bit of fault tolerance. Thus, remotely backing up multi-GB images of Windows workstations over T1s is a non-starter. We require the use of Acronis imaging backups on all systems due to system requirements. That being said, I have remote facilities in my network interconnected with T1 circuits. Whether or not this device is participating in the domain affects the solution. A lot of Linux-based NAS units like Synology, QNAP, et al, have software components imbedded that allow them to participate in Active Directory domains. The important missing information though in my opinion is whether or not the Synology devices are joined to the domain. I'm going to assume that you've insured that the GPO portion of this case is a non-issue, by testing this GPO against a "traditional" UNC share on another Windows system. Since I have almost no rep, I can't ask questions yet, so I'll attempt to ask a question whilst posting an answer and hope I don't get canned. The only software difference I can think of is that at Site A, all the computers were running Windows 8.1 Pro and were upgraded to Windows 10 Pro, whereas at Site B, all computers have fresh installs of Windows 10 Pro. Why is this problem happening so frequently at one site, but almost never at the other site, when both are on the same domain, have the same policy, and are running the same software? There are no signs of connection or permission problems. If, after a failed login, I try to browse directly to \\SynologyServer\ShareName\, the share always loads immediately without any errors. I also have several netmon captures of a login with drives failing to load, but the capture has so much information I'm not sure where to begin. \domain\SysVol\domain.local\Policies' was applied correctly. Sometimes it is 2 boots, but I have had to rarely reboot a computer sometimes 6 or 7 times before the drives appear.įor this last 20% of the time, I will sometimes get errors from the gpupdate process. 50% of the time, a gpupdate will not fix the problem, but after one boot and another gpupdate, the drives will appearĢ0% of the time, it will take multiple reboots (and gpupdate for each boot) before the drives appear.20% of the time, a gpupdate will not fix the problem, but the next boot will be fine.5% of the time a gpupdate or gpupdate /force will cause just one drive to appear.If the gpupdate doesn't work on the first attempt, it will pretty much never work after that (for that boot) 5% of the time a gpupdate or gpupdate /force will fix the problem and the drives will immediately appear.Of the 30% of the time where a problem presents itself: The problem is mostly random, and does not seem to follow any particular user or Workstation. Sometimes it is both drives, sometimes it is one or the other.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |