Copying CLR assemblies across servers

I recently had an Sql Server 2014 r2 server I needed to migrate to Sql Server 2019 r2 with a set of CLR assemblies on it. My plan is to detach each database and reattach them on the new box. The assemblies are transferred along with the database, but they won’t run. I went through the following steps to run them.

Step 1. Click on Programmability, Assemblies under the Database in Sql Server Management Studio.

Step 2: Right click and choose Script Assembly as Create to New Query Editor Window

you’ll get something that looks like this

CREATE ASSEMBLY [Microsoft.SqlServer.Types]

from   XXXXXX

with permission_set=unsafe

Step #3, run the query select * from sys.assemblies you’ll get something that looks like this

name principal_id assembly_id clr_name
Microsoft.SqlServer.Types 4 1 microsoft.sqlserver.types, version=15.0.0.0, culture=neutral, publickeytoken=89845dcd8080cc91, processorarchitecture=msil

Step #4 You have to make the assemblies trusted. Run the following code. Substitute the XXXXX where indicated and the clr_name from above

–run from create assembly after from copied to @asmbin
USE master;
GO
DECLARE @clrName nvarchar(4000) = ‘microsoft.sqlserver.types, version=15.0.0.0, culture=neutral, publickeytoken=89845dcd8080cc91, processorarchitecture=msil’
DECLARE @asmBin varbinary(max) = XXXXXXXX
DECLARE @hash varbinary(64);

SELECT @hash = HASHBYTES(‘SHA2_512’, @asmBin);

EXEC sys.sp_add_trusted_assembly @hash = @hash,
@description = @clrName;

go

Step #5. Here’s the query to list the trusted assemblies (I put XXXX for hash,  you can take that out)

SELECT ‘XXXX’ as hash, description, create_date
FROM sys.trusted_assemblies

run as

SELECT hash, description, create_date
FROM sys.trusted_assemblies

with these results

hash description create_date
XXXX microsoft.sqlserver.types, version=15.0.0.0, culture=neutral, publickeytoken=89845dcd8080cc91, processorarchitecture=msil 1/2/2023

Getting error Azure DevOps services are not available from server xxxxx.visualstudio.com

You could try to clear visual studio cache and TFS cache .

1.Close all instances of Visual Studio

2. Press Windows + R and input the path

%LocalAppData%\Microsoft\Team Foundation\

Then choose the version of TFS, then go to the Cache folder

%LocalAppData%\Microsoft\Team Foundation\{TFS version}\Cache 

I removed this folder and it was sufficient.

Here’s the visual studio cache by the way.

%APPDATA%\Microsoft\VisualStudio

remove the component model cache

%LocalAppData%\Microsoft\VisualStudio\16.xxx\ComponentModelCache

 

for whatever version

 

3. Remove the Cache folder

4. Restart the Visual Studio.

mailwizz failing with VestaCP and MariaDb in Centos 7

I recently had a frustrating problem where I couldn’t upload files into MailWizz host.  This also causes problems with command line CSV imports. I discovered I had to open up /etc/my.cnf and edit the following line to

max_allowed_packet = 110M

then in /etc/php.ini I changed the following two lines
post_max_size = 200M
upload_max_filesize = 500M

then execute

service mariadb restart

Under settings, import/export on the backend I set CLI Import Enabled to Yes and Url Import Enabled to Yes.

 

 

 

Watch out for IPTables and order of execution of rules

I recently need to block Barracuda network ips from accessing my mail server, MailWizz. I did the typical

iptables -A INPUT -s 64.235.144.0/20 -j DROP

iptables -A INPUT -s 209.222.80.0/21 -j DROP

iptables -A INPUT -s 35.176.92.96/27 -j DROP

iptables -A INPUT -s 35.157.190.224/27 -j DROP

iptables -A INPUT -s 5.188.211.0/24 -j DROP

iptables -A INPUT -s 204.101.161.159 -j DROP

iptables -A INPUT -s 207.102.138.158 -j DROP

then

service iptables save

service iptables end

the problem with this setup is that those rules end up getting appended to the end and never get blocked. It’s better to go into the iptables directly. ON Centos 7, that is located in /etc/sysconfig/iptables. I added these lines directly before any of the rules were executed.

-A INPUT -s 64.235.144.0/20 -j DROP
-A INPUT -s 209.222.80.0/21 -j DROP
-A INPUT -s 35.176.92.96/27 -j DROP
-A INPUT -s 35.157.190.224/27 -j DROP
-A INPUT -s 5.188.211.0/24 -j DROP
-A INPUT -s 204.101.161.159/32 -j DROP
-A INPUT -s 207.102.138.158/32 -j DROP

I’m also putting in a post on how to block Amazon Bots.  However you’ll need to redo the above after running these commands in Centos 7

yum install git

git clone https://github.com/corbanworks/aws-blocker.git

yum install jq

cd aws-blocker

bash aws-blocker

iptables-save | sudo tee /etc/sysconfig/iptables

service iptables save

service iptables restart

Then add the above manually and you’ll have both AWS and Barracuda blocked.

VisualChron Fails SSIS Task

I recently had a project with SQL Server 2014 utilizing the Visual Studio 2015 shell for a Sql Server Integration Project. I tried to run the SSIS task in Visual Chron and kept getting errors. After exhaustive research I discovered that I had to make sure to go into the project properties and choose SQL Server 2014 as your TargetServerVersion. Once I did this and recompiled one of my scripts, it worked.

 

Fixing SQL Logins after Migration

I recently migrated a SQL Server 2008 R2 database to SQL Server 2014.  We host with Rackspace, so I had them restore our databases from backup to the new server. I was left with database users that weren’t linked to SQL Server Users.  Even after I added the users they were still not linked together and the system wouldn’t offer me the option. The following SQL allowed me to fix the problem.

  1. Assign ownership of the database to a current user on the new server Alter authorization on database::[DATABASENAME] to [DOMAIN\USERNAME]
  2. Find the users that aren’t associated with their SQL Login with Exec sp_change_users_login ‘Report’
  3. Autofix the logins to link the SQL Server Database User to the SQL Server Login User exec sp_change_users_Login ‘Auto_Fix’,’USERNAME’

The new database clearly won’t have the SQL Server Login Users until you add them so add them manually before you run the above routines.