Elsawin Server

0 views

Skip to first unread message

Cora Devries

unread,

Aug 3, 2024, 1:35:07 PM8/3/24

to nyobarpatha

Error 800706BA is a standard Windows error with many causes. It most often refers to Microsoft COM Internet Services (CIS) on the Distributed Component Object Model (DCOM) client call RPC_S_SERVER_UNAVAILABLE; the RPC server is unavailable (Windows Event ID 1722). It occurs when a RPC query times out and error 800706BA is the result. The following steps have been shown to resolve this issue:

Retry the Recovery Point backup job after a period of time has elapsed

The error can occur when the VSR system is under high CPU or memory usage by other services or applications. Wait until those applications finish and attempt the backup. For best practice guidelines on performing recovery point creation please refer to VSR User's Guide section "Best practices for backing up your data".

Reboot target server

Verify DNS settings when backing up to a network share location

VSR will report this error occurs when DNS servers are not configured properly when backing up to a network share. Possible network connectivity issue usually DNS is not set properly. If the above suggestions do not correct this error, perform the following steps:

1 Verify that address for the configured preferred DNS server on VSR client system on the client is valid and reachable.

2 Use NSLOOKUP and IPCONFIG /ALL to displayed DNS Server settings. Check the TCP/IP configuration for a local incorrect DNS Server settings. Local settings will overwrite settings from the DHCP Server. By deleting the local DNS setting and switching to auto configuration DNS server settings should be corrected.

3 Check if the storage and client systems have DNS entries. If not make sure dynamic updates are enabled on the DNS server and schedule a restart of the netlogon server on each DC.

4 Check for symptoms where new Global Domain Users cannot not be added to a Local Group in Computer Management -> Local Users and Groups -> Groups. Correct this by configuring the network adapters to point to the correct DNS servers on the network. Verify that the VSR client is pointing to the DNS server on same domain as the share.

5 Make sure the authoritative time server is set correctly.

6 Verify that the VSR client system can ping the storage system by fully qualified domain name if not from a command prompt use the ipconfig /flushdns and /registerdns and try again.

7 Make sure that if the VSR client system has multiple adapters, the adapter that resolves to the storage location is listed first in the adapter binding order in the Advanced settings of Network and Dial-up Connections. Otherwise, DNS resolver may use the DNS server for the adapter listed first that may not resolve to the storage location correctly.

Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.

Purpose: This log is the clean and user friendly log file that contains the basic information about the problem. This file shows which SQL server components were detected, the operating system environment, the command-line parameters that were specified, the values that were specified, and the overall status of each MSI and MSP file that was executed.

My error:
Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1. Please update all Visual Studio 2008 installations to SP1 level, by visiting Microsoft Update.

1) Open Management Studio and attempt to connect to the SQL Server instance by ip address. (By the way, you will probably need to use a SQL Server userid/pwd if you aren't already since you're on an Internet host and there is very likely no AD context for Windows auth.)

2) If you can indeed connect to the instance and your database using Management Studio then you've probably missed a connection string somewhere. Try to maintain only 1 location for said connection string, usually in a config file. Examine the error line reported in detail to discover which connectionstring is being used and to verify that it reflects the new server ip.

The connection problem I experienced was due to a firewall setting on the server that hosts MSSQL. The setting gave individual IP addresses access to it which 'works' in our environment since IP addresses are described by our administrator as 'sticky'. Once the Firewall access was granted to my new machine's IP address, the PHP odbc_connect(...) statement I was running in my local WAMP setup completed immediately.

Of the Inbound rules on the server housing MSSQL, I found a rule referring to the MSSQL instance and sure enough found the IP address of my old machine there underneath the properties tab "Scope" as a "Remote IP address". Here's to hoping I remember this whenever I get my next machine! (The decommissioned PC's IP has been removed)

identifying what to use for Server, this must be the Server Name as configured on SQL server instance, this can be found by opening "MicrosoftSql2014 management Studio", then by looking at properties I found the name (DESKTOP-F6T7JPD\sql_Instance_Name)

the second issue actually is that this name must be modified by adding another back slash \ between my PC name and the instance nameso the name found on management studio will be like: PC_Name\Sql_Instance. Note the "\", ... this must be put as Pc_Name\\Sql_Instance.
Note the \\ between PC name and Instance Name!

If so, you may need to remap the SQL users in the database to the SQL logins on the server. To scan to see if you have this problem, you can use EXEC sp_change_users_login 'Report'. The 'Auto_Fix' option will automatically correct issues the system finds. You can also run ALTER USER $User WITH LOGIN $Login to manually correct each mapping individually.

The issue is caused because the SIDs generated for the SQL user in the database on the old server don't match the SIDs for the SQL logins on the new database. The stored procedure corrects the discrepancy.

One possible cause is that the server is not running. If you cannot connect even in the Management Studio, check that the SQL Server service is Started and it has been configured as Automatic so that is is started at boot.