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
Related
We use Azure SQL Database, and therefore had to jump through some hoops to get cross-database queries set up. We achieved this following this great article: https://techcommunity.microsoft.com/t5/azure-database-support-blog/cross-database-query-in-azure-sql-database/ba-p/369126 Things are working great for most of our databases.
The problem comes in for one of our databases which is read-only. The reason it's read-only is b/c it is being synced from another Azure SQL Server to derive its content. This is being achieved via the Geo-Replication function in Azure SQL Database. When attempting to run the query GRANT SELECT ON [RemoteTable] TO RemoteLogger as seen in the linked article, I of course get the error "Failed to update because the database is read-only."
I have been trying to come up with a workaround for this. It appears user permissions are one of the things that do NOT sync as part of the geo-replication, as I've created this user and granted the SELECT permission on the origin database, but it doesn't carry over.
Has anyone run into this or something similar and found a workaround/solution? Is it safe/feasible to temporarily set the database to read/write, update the permission, then put it back to read-only? I don't know if this is even possible - I was told by one colleague that they think it will throw an error along the lines of "this database can't be set to read/write b/c it's syncing from another database..."
I figured out a work-around: Create a remote connection to the database on the ORIGIN server. So simple, yet it escaped me until now. Everything working great now.
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!
I am trying to set up a merge replication using web synchronization between a publishing SQL Server 2012 standard and subscribing SQL Server 2012 Express. After following the instructions provided at Technet, I am stuck on this:
Source: Merge Process(Web Sync Server)
Number: -2147200985
Message: The subscription to publication 'MyMergePublication' has expired or does not exist.
I already verified that SSL certification are good, that I can browse to the publishing machine's URL https:\\mycomputer\replisapi.dll and get the expected output. I already verified that snapshot was set up and I took a giant hammer & use an administrator account to run the pool identity which is really bad security-wise but wanted to validate that it was not security that was tripping me up.
To further the mystery, when I try and fail to sync, the publisher acknowledges that a new subscriber has been registered, but it cannot get the snapshot at all and thus subscriber database is still empty.
On the replication monitor, there are no failed synchronization history, or any errors; all it has to say is that the subscriber is uninitialized, and no more.
Turning up the verbosity of the merge agent, I saw some sql being executed and tried replicating the sql and i found this was failing with same error:
{call sys.sp_MSgetreplicainfo(?,?,?,?,?,?,?,90)}
I called it with only the 3 mandatory parameters supplied and it would fail. That is despite the prior call sp_helpmergepublication does return a row for that publication. Oddly, the content of sp_helpmergepublication does not match what I configured for the subscription (e.g. it says web url is null when viewing the properties correctly shows the web url being set). Not sure that is significant.
The content of sp_MSgetreplicainfo contains a call to another system sprocs that I cannot run for some reason (says not found) so I'm not sure what is actually going on here.
Any clues would be greatly appreciated.
I am using msdeploy (version 2) to transfer a database from machine A to machine B.
On in the database on machine A there are some users that do not exist on machine B, thus the transfer (partially) fails with the message:
Error Code: ERROR_SQL_EXECUTION_FAILURE
More Information: An error occurred during execution of the database script.
The error occurred between the following lines of the script: "3" and "5".
The verbose log might have more information about the error.
The command started with the following: "CREATE USER [someDomain\someUser] FOR LOGIN [someDomain"
Windows NT user or group 'someDomain\someUser' not found.
Check the name again. http://go.microsoft.com/fwlink/?LinkId=178587
The database seems to be transfered, except for the user creation. Does anyone know what state the database is in after this failure?
Is there any way I can transfer the database without the users (or better without specific users) using msdeploy?
Web Deploy uses SMO (SQL Management Objects) to script out and apply the scripts for SQL databases, and exposes most of the SMO settings with the dbfullsql provider (so, most of these options: http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.transfer_properties.aspx). If you want to skip the users due to this kind of login-not-exists or user-not-found error, you should be able to do this by adding the scripting option: copyAllUsers=false to the source of the sync. For example:
msdeploy.exe -verb:sync -source:dbfullsql="Data Source=.\SQLExpress;Initial Catalog=MySourceDb;User Id=localUser;Password=LocalPass",copyAllUsers=false -dest:dbfullsql="Data Source=RemoteSQLServer;Initial Catalog=MyDestDb;User Id=remoteUser;Password=RemotePass"
Incidentally, I am surprised you note the db appears to have been sync'd - I would expect this is not actually the case. If you have the permissions for it, Web Deploy will create the database if it did not already exist when it initially tries to make the connection, but your failure occurred very early in the script execution, and I believe Web Deploy dbfullsql syncs are transacted by default (the db creation is separate from the script execution and is not transacted). Thus the db may exist where it did not pre-sync, but I wouldn't expect the data to be present in it.
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