Multiple valid AD FS configuration databases found in remote SQL Server instance - sql-server

We are attempting to join a newly configured AD FS node into the existing farm. We have tested and confirmed firewall > user access is working fine. When trying to join via the wizard we specify the existing farm server, certificate (has been imported and shows in dropdown list) and service account successfully. It fails with an error:
Multiple valid AD FS configuration databases found in remote SQL Server instance with connection string 'Data Source=REDACTED;Initial Catalog=ADFSConfigurationV3;Integrated Security=True;Min Pool Size=20'. Provide a specific database version when joining the machine.
We attempt to use the script that the wizard creates via an admin powershell and are presented with the same message. I have looked at the SQLConnectionString parameters and cannot see any that would look to specify versions from https://learn.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlconnection.connectionstring?view=netframework-4.8#remarks
On the SQL server side, there is indeed an older database named AdfsConfiguration which has not been edited since 2020-09-06 by checking tables > IdentityServerPolicy.FarmNodes > right click > select top 1000 rows and viewing the Heartbeat property value. On the newer AdfsConfigurationV3 database under the same table and object I see modified 2022-03-30 (today).
How would I go about finding the multiple configuration databases and specifying exactly which to use? Is it safe to detach the AdfsConfiguration database or is this still used/in use by ADFS even with the later 2016 V3 present in a separate database?

• As you have stated that the ADFS server to be added in the farm is running on Windows Server 2016, the FBL (Farm Behaviour Level) version is 3 and the corresponding ADFS Configuration Database Name will be ‘AdfsConfigurationV3’. Thus, the actual databases to be searched for while specifying the configuration database should be ‘AdfsConfigurationV3’.
• If the OS version of the ADFS node server is ‘Windows Server 2012 R2’, then the FBL will be ‘1’ and the ADFS Configuration Database name will be ‘AdfsConfiguration’ while the OS version, if it is ‘Windows Server 2019’, then the FBL will be ‘4’ and ADFS Configuration Database name will be ‘AdfsConfigurationV4’. Also, you should check for the ‘AdfsConfigurationV3.mdf’, ‘AdfsConfigurationV3_log.ldf’, ‘AdfsArtifactStore.mdf’ and ‘AdfsArtifactStore.ldf’ database files in the other ADFS Farm connected servers and accordingly try to form the connection string and connect to the right database.
• It is safe to detach the ADFS database through the SQL query from the original ADFS Server by using the queries below and then copying them and pasting them at a location where SQL databases are stored on the destination ADFS Server.
USE [master]
GO
EXEC master.dbo.sp_detach_db #dbname = N'AdfsArtifactStore'
GO
EXEC master.dbo.sp_detach_db #dbname = N'AdfsConfigurationV3'
GO
Once the ADFS databases are detached using the above query and pasted on the destination ADFS Server, execute the below SQL query to attach the copied databases to the ADFS Server and make it operational.
GO
CREATE DATABASE [AdfsConfigurationV3] ON
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsConfigurationV3.mdf' ),
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsConfigurationV3_log.ldf' )
FOR ATTACH
GO
USE [master]
GO
CREATE DATABASE [AdfsArtifactStore] ON
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsArtifactStore.mdf' ),
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsArtifactStore_log.ldf' )
FOR ATTACH
GO
ALTER DATABASE AdfsConfigurationV3 set enable_broker with rollback immediate
GO
Thus, in this way, you can detach and attach the latest ADFS Database to the preferred primary ADFS Server for it to be replicated and used. But for this, please ensure that you have the ‘OWNER’ permissions access to the ADFS databases in the original and the destination ADFS Servers respectively and while performing the above tasks, ensure that the ADFS Service is stopped and started only when the operation is complete. Post completion of the above tasks, ensure that the connection to the SQL Servers is possible by referring to the documentation link below: -
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-sql
Also, refer to the link below for detailed information on the above: -
https://purple.telstra.com.au/blog/windows-server-2012-r2-adfs-3-0-migrating-adfs-configuration-database-from-wid-to-sql
Though the above link may not be discussing the issue that you are facing, but it resolves your queries to a greater extent.

Related

How to query Azure Master DB from a Linked Server

I am trying to run this query from an instance on premise to the Master database in Azure.
I can query the other database on the Azure instance with my linked server so that is working and the query I'm trying to run, runs when I log onto the Azure instance.
I just cannot get it to run from my server that has a linked server object set up for Azure.
The code I have tried is:
SELECT [database_id],[name],[Compatibility_level],[collation_name],[state_desc]
,[recovery_model_Desc],[is_broker_enabled],[is_cdc_enabled]
FROM [LinkedServerName].[Master].[sys].[databases]
I have also tried it this way:
EXEC ( 'SELECT [database_id],[name],[Compatibility_level],[collation_name],[state_desc] ,[recovery_model_Desc],[is_broker_enabled],[is_cdc_enabled]
FROM [Master].[sys].[databases]') AT [LinkedServerName]
Again with no success. I am getting this error:
Msg 40515, Level 16, State 2, Line 9
Reference to database and/or server name in 'Master.sys.sp_tables_info_90_rowset_64' is not supported in this version of SQL Server.
Any ideas to help me get around this?
When you created the linked server you specified the user database as the “Catalog” database, you did not specified the master database as the catalog (the database used for the linked server). That is the reason you are using cross database queries, and cross database queries using three and four-part names are not supported on Azure SQL Database as explained here.
Additionally not all sys tables are supported on Azure SQL Database. You will find some DMVs available on Azure SQL Database that do not exist on SQL Server on-premises and vice versa.

Specifying schema in SQL server connection

I have a JBoss application that I copied from our production system running in local. This application connects to a SQL server database. I copied also this database in local and can browse it with MS SQL server studio. After a long fight with the users and TCP connections settings in the SQL server. Now I can see how the connection between the JBoss and my copy of the DB is done in local.
However, the problem I am facing is that I get lots of exceptions like
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Invalid
object name 'table_name'.
Obviously the table_name exists in the SQL database as I can browse it, from SQL studio, using the same user JBoss is using to connect. One interesting thing is that when I browse the tables I see their names are in the form of: 'schemaName.table_name' so my only guess is that the schema is expected for the queries sent from JBoss. This is perhaps a problem with the configuration in the SQL because the JBoss is the same, the jars in the JBoss are also the same and the only thing that may be different is the creation of the users for the SQL database.
Does any one in the forum has any idea about what the problem could be or how can I specify the default schema for a certain user, so it is used in the JDBC connection?
To assign a user a default schema:
In SQL Server Management Studio go to Security / Logins / YourUser / UserMapping. There you can set the default schema for each database so you don't have to type the schema before the table names.

"Cannot create an instance of OLE DB provider" error as Windows Authentication user

I am trying to run openrowset from MS SQL Server on an Oracle server.
When i execute the following command:
select * from
OPENROWSET('OraOLEDB.Oracle','srv';'user';'pass',
'select * from table')
the following error occurs
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "OraOLEDB.Oracle" for linked server "(null)".
Can anyone tell me how I can use openrowset with OraOLEDB.Oracle?
I am using 64 bit version of MS SQL Server and Oracle OLEDB driver.
Edit
I have tried this on two machines running Windows 7 x64 & Windows Server 2008 x64 with MS SQL Server 2008 x64. Both showed the same error message.
In SQL Server Enterprise Manager, open \Server Objects\Linked Servers\Providers, right click on the OraOLEDB.Oracle provider, select properties and check the "Allow inprocess" option. Recreate your linked server and test again.
You can also execute the following query if you don't have access to SQL Server Management Studio :
EXEC master.dbo.sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
Ran into this issue where the linked server would work for users who were local admins on the server, but not for anyone else. After many hours of messing around, I managed to fix the problem using the following steps:
Run (CTRL + R) “dcomcnfg”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
Copy the “Application ID” on the properties page.
Close out of “dcomcnfg”.
Run “regedit”. Navigate to “HKEY_CLASSES_ROOT\AppID{???}” with the ??? representing the application ID you copied in step #3.
Right click the “{???}” folder and select “Permissions”
Add the local administrators group to the permissions, grant them full control.
Close out of “regedit”.
Reboot the server.
Run “dcomconfig”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
On the “Security” tab, select “Customize” under “Launch and Activation Permissions”, then click the “Edit” button.
Add “Authenticated Users” and grant them all 4 launch and activation permissions.
Close out of “dcomcnfg”.
Find the Oracle install root directory. “E:\Oracle” in my case.
Edit the security properties of the Oracle root directory. Add “Authenticated Users” and grant them “Read & Execute”, “List folder contents” and “Read” permissions. Apply the new permissions.
Click the “Advanced Permissions” button, then click “Change Permissions”. Select “Replace all child object permissions with inheritable permissions from this object”. Apply the new permissions.
Find the “OraOLEDB.Oracle” provider in SQL Server. Make sure the “Allow Inprocess” parameter is checked.
Reboot the server.
When connecting to SQL Server with Windows Authentication (as opposed to a local SQL Server account), attempting to use a linked server may result in the error message:
Cannot create an instance of OLE DB provider "(OLEDB provider name)"...
The most direct answer to this problem is provided by Microsoft KB 2647989, because "Security settings for the MSDAINITIALIZE DCOM class are incorrect."
The solution is to fix the security settings for MSDAINITIALIZE. In Windows Vista and later, the class is owned by TrustedInstaller, so the ownership of MSDAINITIALIZE must be changed before the security can be adjusted. The KB above has detailed instructions for doing so.
This MSDN blog post describes the reason:
MSDAINITIALIZE is a COM class that is provided by OLE DB. This class can parse OLE DB connection strings and load/initialize the provider based on property values in the connection string. MSDAINITILIAZE is initiated by users connected to SQL Server. If Windows Authentication is used to connect to SQL Server, then the provider is initialized under the logged in user account. If the logged in user is a SQL login, then provider is initialized under SQL Server service account. Based on the type of login used, permissions on MSDAINITIALIZE have to be provided accordingly.
The issue dates back at least to SQL Server 2000; KB 280106 from Microsoft describes the error (see "Message 3") and has the suggested fix of setting the In Process flag for the OLEDB provider.
While setting In Process can solve the immediate problem, it may not be what you want. According to Microsoft,
Instantiating the provider outside the SQL Server process protects the SQL Server process
from errors in the provider. When the provider is instantiated outside the SQL Server process,
updates or inserts referencing long columns (text, ntext, or image) are not allowed.
-- Linked Server Properties doc for SQL Server 2008 R2.
The better answer is to go with the Microsoft guidance and adjust the MSDAINITIALIZE security.
For error 7302 in particular, I discovered, in my registry, when looking for OraOLEDB.Oracle that the InprocServer32 location was wrong.
If that's the case, or you can't find that string in the registry, then you'll have to install or re-register the component.
I had to delete the key from the GUID level, and then find the ProgID (OraOLEDB.Oracle) key, and delete that too. (The ProgID links to the CLSID as a pair).
Then I re-registered OraOLEDB.Oracle by calling regsvr32.exe on ORAOLEDB*.dll.
Just re-registering alone didn't solve the problem, I had to delete the registry keys to make it point to the correct location. Alternatively, hack the InprocServer32 location.
Now I have error 7308, about single threaded apartments; rolling on!
Received this same error on SQL Server 2017 trying to link to Oracle 12c. We were able to use Oracle's SQL Developer to connect to the source database, but the linked server kept throwing the 7302 error.
In the end, we stopped all SQL Services, then re-installed the ODAC components. Started the SQL Services back up and voila!
Aside from other great responses, I just had to give NTFS permissions to the Oracle installation folder.
(I gave read access)
Similar situation for following configuration:
Windows Server 2012 R2 Standard
MS SQL server 2008 (tested also SQL 2012)
Oracle 10g client (OracleDB v8.1.7)
MSDAORA provider
Error ID: 7302
My solution:
Install 32bit MS SQL Server (64bit MSDAORA doesn't exist)
Install 32bit Oracle 10g 10.2.0.5 patch (set W7 compatibility on setup.exe)
Restart SQL services
Check Allow in process in MSDAORA provider
Test linked oracle server connection
Just enable option "Allow in process" on the properties of the OraOLEDB.oracle provider as below
[open server objects > Linked Severs > providers] 1 [right click on
OraOLEDB.oracle > properties ] 2 then choose optaion "Allow in
process" and click ok

MOSS 2007 Unable to Connect to Database after Config Database Move

I am in the process of moving all our SharePoint DB's from a SQL 2005 server to a new 2008 server, and after moving the config database, everything seems ok, except when I click on "Timer Job Status" (under Central Admin > Operations > Global Configuration) I receive a "Unable to connect to database. Check database connection information and make sure the database server is running." error.
I get the following entries in the log regarding this:
12/03/2010
13:51:41.80
w3wp.exe
(0x09E0)
0x09AC
Windows SharePoint Services
General
8e2r
Medium
Possible mismatch
between the reported error with code =
0x8107053b and message: "Unable to
connect to database. Check database
connection information and make sure
the database server is running." and
the returned error with code
0x81020024.
12/03/2010
13:51:45.61
OWSTIMER.EXE
(0x0744)
0x0DD8
Windows SharePoint Services
Database
6f8e
Critical
SQL Database
'SP_Test_Config' on SQL Server
instance 'test-server' not found.
Additional error information from SQL
Server is included below. Cannot open
database "SP_Test_Config" requested by
the login. The login failed.
It should be noted that in order to ensure that it was no longer using the config database on the old server, I detached the original SP_Test_Config database in SQL Management Studio.
Obviously there are still references to the old SP_Test_Config database on the old 2005 server. How do I remove these references? Or, barring that, how do I move the config database in such a way that no references to the old 2005 server will remain?
Thank you in advance!
Not really an answer, but what we ended up doing (basically start from scratch using SQL Aliases):
First, create the SQL Server alias. This will make it so if you need to move the databases again in the future, you can just migrate all the databases to the new SQL Server, and change your SQL Server alias to point at that server. This should save you a lot of trouble and heartache in the future.
Run SQL Server Client Configuration Utility at: C:\Windows\System 32\cliconfig.exe.
Under the Alias tab, create a SQL Server Alias for the new SQL Server.
Now, recreate the farm.
Run stsadm -o preparetomove on all content DB's Backup all content DB's and copy to new SQL server
Remove all servers from farm using SharePoint Configuration Wizard
Recreate farm using SharePoint Configuration Wizard with the alias of the SQL Server you created above
Recreate all web apps with temp content DB's
Run stsadm -o deletecontentdb on all temp content databases created in step 4
Run stsadm -o addcontentdb using copied production databases as content database
Troubleshoot ad nauseum

Microsoft OLE DB Provider for SQL Server error '80040e14' Could not find stored procedure

I am migrating a classic ASP web app to new servers. The database back end is migrating from SQL Server 2000 to SQL Server 2008, and the app is moving from Win2000 x86 to Win2003R2 x64. I am getting the above error on every single stored procedure call within the application.
I have verified:
Yes, the SQL user is set up, using correct username and password
Yes, the SQL user has execute permissions on the stored procedures in the database
Yes, I have updated the TypeLib references to the new UUID
Yes, I have logged into the database via SSMS with the SQL user id and it can see and execute the stored procedures just fine in SSMS, but not from the web app.
Yes, the SQL user has the database set as its default database.
The most frustrating thing is it works fine on the DEV server, but not on the production server. I have gone through every IIS setting 5 or 6 times and the web app is set up precisely the same in both environments. The only difference is the database server name in the connection string (DEV vs prod)
EDIT: I have also tried pointing the prod web box at the dev database server and get the same error so I'm fairly sure the issue isn't on the database side.
Are you sure that you are really connected to the instance and database you think you are (in the App)? It only takes the wrong DB in the connection string to override the default database for the user.
Can you execute some inline SQL on the connection like:
SELECT ##SERVERNAME AS SERVERNAME
,DB_NAME() AS [DB_NAME]
,CURRENT_USER AS [CURRENT_USER]
It might be the schema. Have you set the default schema of your user in the database you are using?

Resources