- #MICROSOFT LYNC WANTS TO USE THE LOCAL ITEMS KEYCHAIN WINDOWS 7#
- #MICROSOFT LYNC WANTS TO USE THE LOCAL ITEMS KEYCHAIN DOWNLOAD#
If you receive this error inside of the Lync Server event log on your Front End server:
I found the solution here: Give it a read, it's very thorough.
The address book should be available in less than an hour. Delete the files GalContacts.db and GalContacts.db.idx. %userprofile%\AppData\Local\Microsoft\Communicator\ _domain. #MICROSOFT LYNC WANTS TO USE THE LOCAL ITEMS KEYCHAIN WINDOWS 7#
On Windows 7 or Vista machines, open Windows Explorer to the directory:. Delete the Existing Local Address Book Files:. reg add HKLM\Software\Policies\Microsoft\Communicator /v GalDownloadInitialDelay /t REG_DWORD /d 0 /f. This can also be done from the command line:. Modify (or Create) the DWORD the registry key “GalDownloadInitialDelay” and set it to 0 (that is a zero). Open the registry to HKLM\Software\Policies\Microsoft\Communicator. #MICROSOFT LYNC WANTS TO USE THE LOCAL ITEMS KEYCHAIN DOWNLOAD#
Force the Lync client to download the address book immediately the next time it starts:. However, as far as we were aware the computers that had the issue never had SEP removed, only installed.The Lync 2010 client or the Office Communicator client does not download the corporate address book and displays a notification: "Cannot Synchronize Address Book" Note: the article specifically refers to this problem occurring on computers that have had SEP removed. The fix we used to resolve the issue is detailed in this MS KB article. It turns out that SEP was modifying Registry keys and telling Windows the default location of the SymRasMan.dll was C:\Program Files\ Symantec\Symantec Endpoint Protection \ instead of the correct %SystemRoot%\System32\rastls.dll. We attempted to set-up the connection manually and found that the Microsoft Protected EAP (PEEP) option was missing from the "Choose a network authentication method:" Clicking on "connect" did nothing but pop-up a window saying "Unable to connect."Īfter digging through the logs we found that the user's credentials were not being passed to the access points. Some users were reporting that their Windows 7 laptops were unable to connect to our corporate WiFi. We also use Symantec Endpoint Protection (SEP) for anti-virus this will become relevant in a moment. Users can walk into any office in the world and use their AD credentials to authenticate to wi-fi. Our corporate network has a global wi-fi solution that uses Cisco access points, PEEP and AD authentication. I don't know if this same procedure will work if you are seeing the file lock with other file types but it is worth a go. Note: the issues we were seeing were occurring with Excel files. Examples: ~$filename.xls or ~$filename.xlsxĪfter deleting the temp files the user could open the file without a problem. Look for a temp file with a "~$" in front of the file name. Remove the tick in "Hide protected operating system files (Recommended)". 
Put a tick in "Show Hidden Files and Folders".On the server open Control Panel/Folder Options/View.Restarting ExtremeZIP and the server did not resolve the issue nor did closing all open file connections. The file lock issue existed regardless of whether or not the user connected via SMB or AFP (using ExtremeZIP). If the user copied the file to their desktop they were able to open it but as soon as they saved it back they would get the same lock message. Log into the WiFi network and enter the authentication details when promptedĪfter removing the shared networks and deleting the items from the Keychain the packet loss stopped and normal WiFi connectivity was restored.Note: there are normally two per network, "System" and "Local Items" Keychains Find the "AirPort network password(s)" that are associated with the problem network and delete them.Click "OK" and then "Apply" to apply the changes.It might be a good idea to remove ALL the saved networks as long as the user knows the passwords for them! Highlight the WiFi connection and click on the "Advanced" tab.We resolved the issue by following these steps: Other computers connected to the same WiFi network did not have this problem. The WiFi router was replaced and a separate WiFi access point was tried and still the drops continued. Cable connections were fine and not all WiFi connections displayed this problem. A MacBookPro running 10.9.4 was experiencing a problem where it would suffer constant connection drops on some WiFi networks with upwards of 70% packet loss.
0 kommentar(er)
