"Revocation process could not continue" error when creating a Fulltext search in SQL Server 2005 - sql-server

When running the following SQL against a SQL Server 2005 Express database:
CREATE FULLTEXT CATALOG My_FTCatalog AS DEFAULT
the following error occurs:
Execution of a full-text operation failed. 'The revocation process could not continue - the certificate(s) could not be checked.'
The error is occurring on a computer that does not have access to the internet, so the certificate information may be 'stale', but its not clear how the above SQL statement triggers the certificate error, and what certificate is at fault.
The SQL is being run with administrative privileges on the computer and in the database.
Thanks in advance.

This is a partial answer/guess to my question, but I hope if someone else comes to this question, they are able to benefit from the answer.
The workaround is to configure Full Text to not verify signatures. This is accomplished by executing the following SQL Command:
EXEC sp_fulltext_service 'verify_signature', 0;
GO
Based on the above setting of not verifying signatures, I found the following page:
https://msdn.microsoft.com/en-us/library/ms142595%28v=sql.90%29.aspx
This pages indicates that the filters used by the Full Text search need to be signed, which would explain why an error involving certificates could be generated when creating a Full Text database.
This pages provides a map of the components that make up the Full Text search architecture, provides some insight into the executable or *.dll files that may need to signed:
https://technet.microsoft.com/en-us/library/ms142541%28v=sql.90%29.aspx
The error in the question references the "revocation process". On the computer that is producing the error, another application displayed an error in it's certificate properties window that said:
Windows cannot determine the validity of this certificate because it cannot locate a valid certificate revocation list from one or more of the certification authorities in the certification path.
The computer producing the error does not have access to the internet, which prevents the OS/certificate management software from being able to validate the revocation lists.
So the 'guess' about what is happening is that when the Full Text database is created, one step in the database creation process is to validate the signatures of the filters used by the Full Text search. Part of the validation of the signatures includes validating the revocation list, but this cannot be completed because the computer is not on the internet, which results in the production of the error.
I hope this helps someone.

This may or may not help future users, but I was able to fix the
'The revocation process could not continue - the certificate(s) could
not be checked.'
issue by making a change to the STATE registry file. However, the installers I was was trying to run would get this error when trying to install Windows Updates with an offline installer.
Open REGEDIT.exe and change STATE from 1000 to 23c00 in:
HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERION\WINTRUST\TRUSTPROVIDERS\SOFTWAREPUBLISHING\STATE
You are looking for the WinTrust folder which may or may not be in currentversion.
If this helped you, mark it up!

Related

SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER- have tried everything

I have created a SSIS package and I am trying to run it locally. We use package configurations that point to sql tables and a XML config file. The package ran successfully for about a week, even when deployed to a SQL Server Agent Job in our STAGE environment.
Now, the only way I can get the package to run is by not using the Package Configurations and choosing EncryptSensitivewithPassword. If I change the package to DontSaveSensitive, I continuously get the error below:
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 11.0" Hresult: 0x80040E4D Description: "Login failed for user 'Test_User'.".
Error: 0xC020801C at AgentCompany, Lookup [37]: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Test" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
It is so strange that about a week ago, this package ran fine with the configurations and the DontSaveSensitive Option.
I have updated the config file to ensure that it is establishing the connection string to the appropriate database. I also test the connectivity on the connection managers and they all test successfully.
I also double checked the SQL Database where the user is trying to connect to ensure that it has permissions there and it does.
I am very confused. Please Help!
Updating dtsconfig file
Re-creating the connection managers
Making some DFT task DelayValidation to true
Changing the RunTime to 32 bit
EncrpytPasswordSensitive with package configs removed---This works but this is not the standard at my company and this is not how I developed and tested the package before
When you open/run a package, an OnInformation event is fired that says something like
The package is attempting to configure from the XML file "c:\ssisdata\so_56776576.dtsconfig".
When Visual Studio/SSDT opens/runs a package which says it uses configuration but for reasons, cannot get them, you should then see messages like
Warning loading so_56776576.dtsx: Failure importing configuration file: "c:\ssisdata\so_56776576.dtsconfig"
and
Warning loading so_56776576.dtsx: The configuration file "c:\ssisdata\so_56776576.dtsconfig" cannot be found. Check the directory and file name.
and
Warning loading so_56776576.dtsx: Failed to load at least one of the configuration entries for the package. Check configuration entries for "Configuration 1" and previous warnings to see descriptions of which configuration failed.
If someone has manually edited the config file and broken the XML, you'd see a warning like
Cannot load the XML configuration file. The XML configuration file may be malformed or not valid
The important thing to note with regard to configuration - if a configuration cannot be found, SSIS will continue along with the design time values. That is why it is crucial to check the warnings emitted when your package runs. If you are running manually, ensure that you have /rep ew specified so you report Errors and Warnings.
Guesses as to root cause
The package has the protection level of EncryptSensitiveWithUserKey which means the AD credentials of the package creator are used to hash things that might have sensitive information in them. I could be using AD authentication in my connection string and specify that the connection should be trusted but that entire block is still going to get encrypted against my Active Directory account. When you come along and attempt to maintain the package, it's not going to be able to decrypt the sensitive data as you are not me.
The two ways around that are to use a shared key (EncryptSensitiveWithPassword/EncryptPackageWithPassword) which is cumbersome to deal with plus it goes against the whole spirit of secrecy since everyone knows the secret. The other approach as you've identified is DontSaveSensitive and that's my go to for all of this.
The problem to be overcome is that with DontSaveSensitive is that every time you save, SSIS is going to wipe out any knowledge of user name and password from places that might be holding on to it - like a connection manager. The 2005/2008 strategy to hedge against this was to use Configuration or explicit overrides at run time to supply user name and password. My typical approach was to use configuration based on a table instead of XML as I was better at securing sensitive data in a table than I was mucking with ACL on the file system. The other challenge we had with multiple developers and file based configuration was that either everyone had to set their file systems up the same (and we developers are unique rainbow snowflakes so that's unlikely) or we need to use a network shared file which is great until someone adds their own values to it and breaks it or removes your changes or any of a host of other challenges.

Cannot deploy SSIS project - Error during execution of "encrypt_binarydata"

I have a SSIS project that I have created that has the DontSaveSensitive protection level and has happily deployed to the local server several times before today. I am now, however, getting the following error on deployment:
A .NET Framework error occurred during execution of user-defined
routine or aggregate "encrypt_binarydata":
System.IO.FileLoadException: Could not load file or assembly
'System.Core, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089' or one of its dependencies. Not
enough storage is available to process this command. (Exception from
HRESULT: 0x80070008) System.IO.FileLoadException: at
Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.CreateSymmetricKey(String
algorithm) at
Microsoft.SqlServer.IntegrationServices.Server.Security.CryptoGraphy.EncryptBinaryData(SqlString
algorithmName, SqlBytes key, SqlBytes IV, SqlBytes binaryData) .
(Microsoft SQL Server, Error: 6522)
I have had a google but come across nothing that specifically references encrypt_binarydata. There are a number of references to deploy_project_internal or untrusted assemblies but nothing on this particular issue.
The important part seems to be
Not enough storage is available to process this command
but I can't make head or tail of this as there are many gigabytes of RAM going spare and plenty of drive space to use so the resources shouldn't be problem.
Can anyone shed any light on what this error is referring to and ideally how I can resolve it?
Turns out this is a problem with permissions that gets very muddied deep down in the inner working of the SSISDB, between SQL and dll files. The error message in the original question is actually a bit of a red herring and the real problem was the same as the one solved in this excellent resolution.
For posterity's sake in case that answer ever disappears (as well as for lazy people that don't want to click another link), here is the referenced answer in full
Credit to Remus Rusanu
Assemblies with EXTERNAL_ACCESS are, through some convoluted path, falling under the EXECUTE AS path. The problem appears when the 'dbo' cannot be mapped to a valid login. dbo's login is the login with the SID the owner_sid value in sys.databases. Unless an AUTHORIZATION clause was used in CREATE DATABASE the owner_sid is the login sid of the principal issuing the CREATE DATABASE statement. Most times this is the Windows SID of the user logged in and issuing the CREATE DATABASE. With this knowledge in hand one can easily envision the problems that may arise:
copy database: CREATE DATABASE was issued on machine A by an user local to A (ie. MachineA\user or DomainA\user) then the database was copied to machine B (via backup/restore or via file copy). The owner_sid is preserved by file copy as well as by backup/restore, this on machine B the owner_sid is invalid. Everything requiring EXECUTE As fails, including loading assemblies from the database.
tombstoned account. CREATE DATABASE was issued by an user that has left the company. The AD account is deleted and all of the sudden EXECUTE AS mysteriously fails, including loading assemblies.
disconnected laptop. CREATE DATABASE was issues when the laptop was connected in the work network. At home you can log in using Windows cached credentials, but EXECUTE AS wants to connect to the unavailable AD and fails. Loading assemblies also fails. Problems mysteriously resolves itself next day at work, when you're again within reach of AD.
spotty AD connectivity. The EXECUTE AS does not uses system cached credentials and connects to the AD every time. If the AD connectivity has issues (timeout, errors) those issues manifest as similar timeouts and errors in EXECUTE AS, including loading assemblies
All these issues can be diagnosed by simply running: EXECUTE AS USER = 'dbo'; in the context of the problem db. It it fails with an error then the cause of your assembly load problems is the EXECUTE AS context of dbo.
The solution is trivial, simply force the owner_sid to a valid login. sa is the usually the best candidate:
ALTER AUTHORIZATION ON DATABASE::[<dbanme>] TO sa;
The funny thing is that the database may seem to be perfectly healthy; tables are available and you can run selects, updates, deletes, create and drop tables etc. Only certain components require EXECUTE AS:
code signing requires the code to have an EXECUTE AS clause
assembly validation
explicit EXECUTE AS in T-SQL code
Service Broker message delivery (including Query Notifications)
The latter is the most often seen culprit, as applications relying on SqlDependency all of a sudden seem to stop working, or have random problems. This article explains how SqlDependency ultimately depends on EXECUTE AS: The Mysterious Notification

SQL Server Management Tools Installation fails with registry Wow6432Node key's (default) value

On Windows 7 x64, SQL Server 2014(x64) Management Tools installation fails with the following error;
Feature: Management Tools - Complete
Status: Failed: see logs for details
Reason for failure: An error occurred for a dependency of the feature causing the setup process for the feature to fail.
Next Step: Use the following information to resolve the error, and then try the setup process again.
Component name: SQL Server Management Services
Component error code: 1406
Component log file: C:\Program Files\Microsoft SQL Server\120\Setup Bootstrap\Log\20140719_170948\sql_ssms_Cpu64_1.log
Error description: Could not write value to key \SOFTWARE. Verify that you have sufficient access to that key, or contact your support personnel.
I monitored installation with Process Monitor and find that it is trying to write(RegSetValue) HKLM\SOFTWARE\Wow6432Node\(Default) value which results in "Access Denied".
So, when i try to change that key's default value within regedit, it is not allowed too;
Cannot edit : Error writing the value's new contents..
For Wow6432Node key, i grant permissions to following users/groups; Everyone, Current Admin Account, Administrators, System but that did not help to change that default value even with regedit.
I could only think about registry corruption or some windows bug or may be some other program intervention, so, i disabled antivirus app. What might it be and how could i solve it?
After trying several things, finally, i applied the following and it worked. Restart may be required after applying it.
regdacl HKLM\SOFTWARE\Wow6432node /gga:F /ggu:F /ggs:F
Download regdacl here
http://www.heysoft.de/en/software/regtools.php?lang=EN

ODBC Logging of Requests

This article here http://msdn.microsoft.com/en-us/library/bb188204%28v=sql.90%29.aspx?ppud=4 describes how to log SQL requests sent via ODBC.
Does anyone know the registry key to use for Access 2010? I searched the registry and found an entry for TraceSQLMode in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\ODBC and turned it on. I ran a few queries from Access out to a remote SQL Server instance, but then search as hard as I could, I couldn't find an sqlout.txt file.
I've searched the registry for another key, but can't find one.
How about:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ODBC]
Values:
"TraceODBCAPI"=dword:00000000
"DisableAsync"=dword:00000001
"TraceSQLMode"=dword:00000000
"QueryTimeout"=dword:0000003c
"LoginTimeout"=dword:00000014
"ConnectionTimeout"=dword:00000258
"TryJetAuth"=dword:00000000
"FatBlastRows"=dword:ffffffff
"FatBlastTimeout"=dword:00000003
"AsyncRetryInterval"=dword:000001f4
"AttachCaseSensitive"=dword:00000000
"FastRequery"=dword:00000000
"ODBCISAMAttach"=dword:00000000
"PreparedInsert"=dword:00000000
"PreparedUpdate"=dword:00000000
"SnapshotOnly"=dword:00000000
"AttachableObjects"="'TABLE','VIEW','SYSTEM TABLE','ALIAS','SYNONYM'"

SQL Agent Job - Connection may not be configured correctly or you may not have the right permissions on this connection?

I'm getting this error when running an SSIS package through SQL Agent
Failed to acquire connection "ORACLE ADO.NET". Connection may not be configured correctly or you may not have the right permissions on this connection.
When I log on as the SQL Agent User and run the ssis package directly it is fine. When I then execute it through the SQL agent job, it fails.
I've read around extensively on this topic, and it seems a lot of the advise concerns how you are logged in, configuring of proxy accounts, etc, etc, etc, none of which has been helpful.
I am logging onto an Oracle database with an ADO.NET conncetion. The connection string is as follows (datasource, userid and password have been changed):
Data Source=DATASOURCE;User ID=userid;Password=password;Persist Security Info=True;Unicode=True;
I'm loading this from a registry setting using package configuration. To check that I am getting the correct string, I am writing it into a temporary log table. I am definately getting the string I need from the correct registry setting.
I've tested the oracle login credentials though PL/SQL developer, and it lets me login just fine.
As far as I can tell, as I'm using an explicit user name and password for the Oracle connection it just shouldn't matter who the SSIs pacakge is run as. The only point of failure that Ican see would be the reading of the information from the registry, but that seems fine.
I'm really quite baffled, I must confess, and would appreciate any help some of the splendid experts here can offer.
Many thanks,
James
Ok, tracked this one down after quite a lot of pain.
It was working fine on one environment, but not another, so I fired up Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and ran a package through the SQL Agent job, comparing which system entities were hit on each enviroment.
On the failing environment, at the point of the bulk transfer operation, the package attempted to get the Oracle 11 client DLL, and then hung.
I knew that this was installed, and, moreoever, the DLL path was a system environment setting. After further investigation it was revealed that the server had not been rebooted since the Oracle Client install and the SQL Server Agent process had not bee recycled.
Yes, can you believe it, the old helpdesk fix "Can you reboot your computer?" worked.
Sigh!
We had issues at a client with running packages connecting to Oracle before stored on our sql server instance. The work around we found was to change the package property, protection level, to "Dont save Sensitive Data" and for security purposes, we encrypted the username and password in the package configuration that was decrypted by a udf in sql server. Of course, before you try the whole encryption part, I would recommend putting the username and password in the package configuration without encrypting the values to see if changing the protection level setting is the solution to your specific problem. I hope this helps.
I was getting this error when tnsnames.ora file did not have a valid entry for the environment

Resources