locked
Install-CSDatabase -Update fails with "the network name cannot be found" RRS feed

  • Question

  • Hello,

    a customer is trying to update Backend Databases after the installation of the latest CU.

    Install-CsDatabase fail with "the network name cannot be found".

    The Backend is using SQL Always ON.

    We didn't face this issue when we installed the system. However, since then a new admin joined the company and he is now responsible for SfB.

    The Admin has sysadmin rights on the SQL server and also local admin rights on the windows server where SQL is installed.

    Somehow it seems that Install-CSDatabase tries to access the DB Path via UNC and ADmin Shares (C$, etc.).

    But those admin shares are not available from the Always On listener name.

    Could this be a misconfiguration on the SQL side?

    Thanks for your help!

    Christian

    Thursday, January 17, 2019 8:08 PM

Answers

  • Hi,

    i also had this problem with an AlwaysOn Database. And i could solve it with this Website

    https://uclobby.com/2019/01/24/install-csdatabase-command-execution-failed-the-network-path-was-not-found-alwayson-backend/

    I had to take the Primary SQL Server. And dont take -ConfiguredDatabases because is always had the error.

    Did it for every DatabaseType as single command.

    And if you have the Default SQL Instance, you have to write -SQLInstanceName ""

    So the finally Powershellcommand was

    Install-CsDatabase -Update -DatabaseType User -SqlServerFqdn PRIMARYSQLSERVER  -SqlInstanceName ""

    Install-CsDatabase -Update -DatabaseType Application-SqlServerFqdn PRIMARYSQLSERVER  -SqlInstanceName ""

    and so on.

    Markus

    Thursday, January 31, 2019 8:15 AM

All replies

  • Hi Christian,

    Please try including  the -DatabasePaths switch pointing to the correct location of the files.

    Hope this helps!

    ---------------------------------------------------------------------------------------------------------

    Please don't forget to “mark the replies as answers” if they helped, also set "like" it’s a boost for us to keep blogging J

    Click here to learn more. Visit the dedicated Community forum to shareexplore and talk to experts about Microsoft Kaizala.


    Friday, January 18, 2019 5:22 AM
  • Hi,

    Please take a look at the SQL configuration regarding port and the corresponding instances.

    Based on my research, if you want to go with custom ports for SQL server it is better to go with named instances. 

    If you want to use the default instance, you will need to use the default tcp port of 1433.

    Here some reference:

    https://social.technet.microsoft.com/Forums/lync/en-US/41f627bd-e062-40b1-af31-481465243e94/lync-setup-and-sql-shared-instance-issues?forum=lyncdeploy

    http://www.wavecoreit.com/blog/2015/skype-for-business-sql-error-system-io-ioexception-the-network-name-cannot-be-found/

    Kind regards,

    Calvin Liu


    Please remember to mark the reply as an answer if you find it is helpful. It will assist others who has similar issue. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, January 18, 2019 9:59 AM
  • Hi Thuyavan Ganesan,

    I did that. Unfortunately it didn't help.

    Also the "-UseDefaultSqlPaths" parameter doesn't help.

    Thanks

    Christian

    Friday, January 18, 2019 8:23 PM
  • This SQL Server is using a named instance listening on Port TCP 1433.

    As I wrote, when we published the Topology and created those DBs, everything worked fine...

    Thanks

    Christian

    Friday, January 18, 2019 8:24 PM
  • I have same problem, but on default instance

    AG listener on same port 1433.

    Friday, January 25, 2019 3:20 PM
  • I could narrow it down to missing permissions. Took a network trace. When my SfB Server communicates with SQL an error is returned when SfB tries to query some registry keys. Remote Regiistry service is runnning and permissions are set for local administrators. The user account I work with is local admin on both SQL machines. So somehow those admin permissions are not applied when accessing the server remotely. After investigation I came to the conclusion that UAC token filtering must be in place - and in fact it is. However, couldn’t test if disabling helps because this requires a restart of the server. The SQL server hosts also other DBs, so we have to wait for a maintenance windows to test. Will keep the thread updated once we were able to test. Christian
    Friday, January 25, 2019 3:51 PM
  • Hi Chiristian,

    Ok, thanks for sharing the tracking progress, please feel free to share with us if any update.

    Kind regards,

    Calvin Liu


    Please remember to mark the reply as an answer if you find it is helpful. It will assist others who has similar issue. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, January 29, 2019 4:23 PM
  • Hi,

    i also had this problem with an AlwaysOn Database. And i could solve it with this Website

    https://uclobby.com/2019/01/24/install-csdatabase-command-execution-failed-the-network-path-was-not-found-alwayson-backend/

    I had to take the Primary SQL Server. And dont take -ConfiguredDatabases because is always had the error.

    Did it for every DatabaseType as single command.

    And if you have the Default SQL Instance, you have to write -SQLInstanceName ""

    So the finally Powershellcommand was

    Install-CsDatabase -Update -DatabaseType User -SqlServerFqdn PRIMARYSQLSERVER  -SqlInstanceName ""

    Install-CsDatabase -Update -DatabaseType Application-SqlServerFqdn PRIMARYSQLSERVER  -SqlInstanceName ""

    and so on.

    Markus

    Thursday, January 31, 2019 8:15 AM
  • To Christian: disable UAC don`t make a trick for me.

    To Markus: and your`s receipt is working one :)

    Thursday, January 31, 2019 7:30 PM
  • Thanks Markus! Your tip also helped in my scenario! Cheers Christian
    Saturday, February 2, 2019 9:45 PM
  • Hello,

    Having a different scenario where the tip by Markus was the solution after this problem had been driving me mad for 2 days. Thanks a lot Markus!

    For a record, few details:

    Environment: 
    - migration from Lync Server 2010 to Skype for Business Server 2015
    - standalone Backend SQL 2012 Standard (x64) server with the only (default) instance 
    - this server needs to be used as a new location for Central Management Store

    Step: pre-installing CMS database as a preparation to actual move

    Error:
    PS > Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn SQLBE.domain.local -UseDefaultSqlPaths
    WARNING: Install-CsDatabase failed.
    Install-CsDatabase : Command execution failed: Object reference not set to an instance of an object.
    At line:1 char:1
    + Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn SQLBE.domain.local ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation: (:) [Install-CsDatabase], NullReferenceException
        + FullyQualifiedErrorId : ProcessingFailed,Microsoft.Rtc.Management.Deployment.InstallDatabaseCmdlet

    Troubleshooting done:
    1. The cmdlet errors out after reading the "HKLM\SOFTWARE\Microsoft\Microsoft SQL Server" subkeys on the SQL server via remote registry.
    2. Setting -SqlInstanceName to "Default", "MSSQLSERVER", etc. resulted in connection error to "SQLBE.domain.local\Default", etc. 
    3. Setting the -SqlInstanceName to "" resolved this!

    BTW, Install-CsDatabase -Update previously run against the same SQL server after CU installation was running fine without specifying the -SqlInstanceName switch at all. So the problem occurred only for the -CentralManagementDatabase option.

    • Edited by egolov Thursday, March 21, 2019 2:16 PM
    Thursday, March 21, 2019 2:09 PM
  • Excellent!!! Thank for your help!
    Tuesday, September 3, 2019 7:17 AM