none
Lync Replication won't work with file share on NetApp NAS RRS feed

  • Question

  • Lync EE was deployed with a file share that exists on a NetApp file share.  The topology deployed with out any errors and the permission were created on the file share without issue.  However, replication does not work, and the status for get-csmanagementstorereplication is uptodate:false.  There are no errors thrown in the event log.  I do have an error in the OCS logger when tracking XDS_Master_Replicator of the following:

    TL_ERROR(TF_COMPONENT) [0]0678.0770::07/27/2011-18:55:35.069.0000057a (XDS_Master_Replicator,MasterReplicationAgent.QueryChangesImpl:masterreplicationagent.cs(724))Query changes operation failed. Exception [System.IO.IOException: The account used is a computer account. Use your global user account or local user account to access this server.

    If I create a new file share on a windows server, restart all services on the front end and re-publish the topology, then replication works fine. 

    Are there any known issues with hosting the File Share for Lync on a NetApp NAS?

     

    Wednesday, July 27, 2011 7:52 PM

All replies

  • Hi,

    Does your Lync Server Replica Replicator Agent start  successfully?

    Would you please run invoke-CsManagementStoreReplication on the CMS server?

    If you get error Would you please check if this article apply to your question?

    http://ms-uc.herber.co/?p=141

    And here is another link for you to troubleshoot the CMS replication issue.

    http://www.ocspedia.com/fe/Lync_Server_2010_Store_Replication.aspx?ArticleID=112

    Another more information just for your reference.

    http://blogs.technet.com/b/jenstr/archive/2010/10/13/what-is-central-management-store-cms.aspx

    Hope this useful!

    Regards,

    Sharon


    Friday, July 29, 2011 6:32 AM
    Moderator
  • Thanks, unfortunately I've already searched these links and they are not the same issue.  The Lync Server Replica Replicator Agent restarts fine without error.  The Lync Server Master Replicator Agent aslo starts without error.  There are no errors or warnings in the event log.  Invokeing the replication does nothing.  I've restarted all services and servers many times. 

    The only error I'm able to find is the one in my original post above.

    Jeremy

    Friday, July 29, 2011 2:30 PM
  • The only error I'm able to find is the one in my original post above.


    The replicas are authenticating to the file store using computer accounts and not the user ones. For some reason netapp NAS does not like it. Either it is configured to reject computer account auth or cannot find computer accounts in AD.

    I had the similar error in an environment which was using similar setup. It was a root/child domain environment with RTC universal groups in the root domain and all servers/NAS in the child domain. They were not able to fix the issue and ended up moving the file store to a windows server.

     

    In another environment with a single domain, netapp cifs store was successfuly used for the lync filestore. netapp was running 7.3.3 firmware. 

    Saturday, July 30, 2011 4:59 PM
  • Hi,Jeremy,

    Any updates?

    Regards,

    Sharon

    Monday, August 8, 2011 1:33 AM
    Moderator
  • The solution is simply to add a SPN for the Filer computer object. By default, NetApp Filer only provide basic Netbios integration in a Windows domain.

    As Lync relies on Network Service (computer) to authenticate to the file server, Kerberos is needed and then a SPN.

    Use SetSpn to register it.

     

    Regards

     

    Stephen

    Tuesday, August 9, 2011 9:11 AM
  • I created a Kerberos account within Lync using new-cskerberosaccount, and assigned it to the site.  Wouldn't this take care of creating the SPN used by the Lync services within AD?

    Jeremy

    Tuesday, August 9, 2011 3:00 PM
  • Based on the following statement, does this mean using NAS is not supported?

    Microsoft Lync Server 2010 communications software supports using file shares on either direct attached storage (DAS) or a storage area network (SAN), including Distributed File System (DFS), and on a redundant array of independent disks (RAID) for file stores. 

    http://technet.microsoft.com/en-us/library/gg399073.aspx

    Jeremy

    Tuesday, August 30, 2011 12:16 PM
  • I encountered the same error and found the solution on this post:

    http://tst.social.technet.microsoft.com/Forums/en-US/ocsplanningdeployment/thread/773d5167-0d4c-4a1e-8399-10d78ff7aeb5?prof=required

    The missing right was not related to changing the contents of the share, but administering the share permissions.  The NetApp admin was able to grant the Lync Administrator the equivalent rights to local admin on the VFiler (which we tested by changing share permissions using the Shared Folders MMC Snap-in).  After that change we were able to enable the topology without errors.


    James Denavit MCSE, MCITP Exchange 2010, MCITP Lync Server 2010

    Tuesday, February 14, 2012 12:25 AM
  • Hello

    I had the same problem. The hostname had no spn entrys in AD. With setspn -l can you check if the spns are correct. With the correct spns, teh replication works fine.

    Hannes

    Tuesday, July 10, 2012 12:03 PM
  • I was getting the below error in the Netapp log: No login workstation trust account 0xc0000199 Setting the SPN resolved the issue and Lync replication is now working. Thanks for the tip!
    Friday, September 28, 2012 11:37 AM
  • We had a similar problem where the lync 2010 and lync 2013 file shares were pointed to <NetAppPublicName> but the NetApp's hostname was different <NetAppHostName>. Basically our computer object's name didnt align with what we were advertising to users/Lync and just had a DNS alias to make it work for normal CIFs shares (out of band management vs public facing names and IPs). I added a second set of SPNs to the NetApp AD computer object to match the name Lync was looking for. So now I have 6 SPNs instead of the previous 4 for the AD NetApp Computer Account.

    So SPNs should be:
    HOST/<NetAppHostName>
    HOST/<NetAppHostName.FQDN>
    NFS/<NetAppHostName>
    NFS/<NetAppHostName.FQDN>
    HOST/<NetAppPublicName>                  <-----new
    HOST/<NetAppPublicName.FQDN>         <------New


    Thursday, May 16, 2013 2:15 PM