Microsoft SQL Server Management Studio: cache is out of date

fernando

Es agosto, el software tambien necesita vacaciones…

Si durante las consultas a algunas tablas en MSSMS aparece el error «The Visual Studio componente cache is out of date» la solución rápida y sencilla pasa por vaciar la carpeta temporales de windows %TMP%

C:\Users\nombre_usuario_windows\AppData\Local\Temp\

Si además el servidor SQL esta en medio de la playa mientras tu sigues programando, puedes probar a seguir con la limpieza de más memorias intermedias, si utilizas Server 2016 o Azure puedes limpiar la cache de los procedimientos de la base de datos:

USE NombreDeMiBBDD;
GO
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;

 

Mientras esperas que la consulta devuelva los valores esperados ;D

 

 

Transferir funciones FSMO

fernando

A la hora de incorporar nuevos servidores en un directorio activo, debemos revisar que funciones queremos transferir antes de dar de baja alguno. En entornos sencillos en los que un equipo es el único encargado de todos ellos debemos:

  1. Añadir el nuevo servidor al dominio existente
  2. Instalar y configurar los roles de Directorio Activo
  3. Migrar las funciones: RID, Controlador principal de dominio e infraestructura, de forma gráfica podemos hacerlo desde la gestión de «Usuarios y equipos de Active Directory». Pulsaremos sobre «Cambiar» en cada una de las tres pestañas, debemos hacerlo desde el sistema operativo más reciente:
  4. Consultamos las funciones FSMO con el comando: «netdom query fsmo» veremos que todavía queda por transferir «Maestro de esquema». Para realizado desde la interfaz gráfica ejecutamos desde la línea de comandos con permisos de administrador (dependerá de la versión de Windows): 
    regsvr32 schmmgmt.dll
  5. Iniciamos «mmc» y añadimos el complemento «Esquema de Active Directory» pulsamos con el botón derecho sobre el nodo y seleccionamos la opción de «Cambiar el controlador de dominio de Active Directory…» y/o «Maestro de operaciones» seleccionado «Cambiar» como en pasos anteriores.

Desde línea de comandos, ejecutamos «ntdsutil.exe«:

roles
connections
connect to server NombreDelServidorDestinoFuncion.local
q
transfer naming master
...

Siempre podemos pulsar «?» en la utilidad para ver que comandos tenemos disponibles

Para comprobar ejecutamos:

netdom query fsmo

ACTUALIZADO: es posible realizarlo mediante Powershell igualmente…

Move-ADDirectoryServerOperationMasterRole -Identity "NombreDelServidorDestinoFuncion.local" PDCEmulator
Move-ADDirectoryServerOperationMasterRole -Identity "NombreDelServidorDestinoFuncion.local" RIDMaster
Move-ADDirectoryServerOperationMasterRole -Identity "NombreDelServidorDestinoFuncion.local" Infrastructuremaster
Move-ADDirectoryServerOperationMasterRole -Identity "NombreDelServidorDestinoFuncion.local" DomainNamingmaster
Move-ADDirectoryServerOperationMasterRole -Identity "NombreDelServidorDestinoFuncion.local" SchemaMaster

get-addomain | select InfrastructureMaster, PDCEmulator, RIDMaster
Get-ADForest | select DomainNamingMaster, SchemaMaster

Plesk + Dotnetnuke + Let’s Encrypt = CMS + SSL

fernando

Algunos gestores de contenidos, como en este caso Dotnetnuke, tienen reglas propias de redirección que pueden interferir a la hora de instalar certificados gratuitos de Let’s Encrypt desde panel de control Plesk. Existen varias opciones, pero una de la más sencilla para este problema concreto es cambiar el tratamiento de las redirecciones del CMS:

    <friendlyUrl defaultProvider="DNNFriendlyUrl">
      <providers>
        <clear />
        <add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="humanfriendly" />
      </providers>
    </friendlyUrl>

Sustituyendo «advanced» por «humandfriendly«, lo que dejará el sitio añadiendo la extensión .aspx de nuevo generando el directorio «\.well-known\acme-challenge\» que incluye la descarga del ficheros sin extensión como texto plano en su propio web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <validation validateIntegratedModeConfiguration="false" />
      <staticContent>
         <clear />
         <mimeMap fileExtension="." mimeType="text/plain" />
      </staticContent>
      <handlers>
      <clear />
      <add name="StaticFile" path="*" verb="GET" modules="StaticFileModule" resourceType="Either" />
      </handlers>
   </system.webServer>
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</configuration>

Ahora podemos volver a dejar la redirección como «advanced». Si, la otra opción es añadir el fichero anterior en el directorio indicado, Let’s Encrypt creará una petición de comprobación del tipo:

http://midominio.es/.well-known/acme-challenge/8-TsVgjMp5v3BRkUVk4zwdiCVDlSkDaf…b

A partir de versiones más modernas, podemos añadir una configuración específica de URLs amigables desde la configuración Host en Sistemas > Configuración del sisstema > Configuración Avanzada > Configuración de URLs amigables

Añadimos las reglas de redirección de IIS para no afectar al directorio:

<configuration>
<system.webServer>
    <rewrite>
      <rules>
        <clear />
        <rule name="LetsEncrypt" stopProcessing="true">
            <match url=".*" />
            <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                <add input="{REQUEST_URI}" pattern=".well-known/" />
            </conditions>
            <action type="Rewrite" url="{REQUEST_URI}" />
        </rule>
    </rewrite>
</system.webServer>    
</configuration>

 

Si pese a ello sigue sin poder acceder a la ruta, puedes deshabilitar temporalmente desde Plesk, el soporte para .NET y renovar manualmente.

Lista de revocación en servidor externo

fernando

Dependiendo de la complejidad de la infraestructura PKI de la organización, podemos desde la entidad de certificación publicar automáticamente en servidores externos, en este caso IIS, los datos.

Para ello compartimos una carpeta en el equipo con el servidor web asignando permisos de acceso y NTFS sobre el nombre de la máquina.

Añadimos en la publicación de la CA una nueva ruta hacia nuestro servidor local, el nombre del fichero y la ruta final debe ser el mismo que el expuesto externamente para el CRL:

file://\\servidorLocal\CA\<nombre de CA><sufijo de nombre de lista CRL><diferencias entre listas CRL permitidas>.crl

En nuestra entidad de certificación tendremos de la siguiente manera la publicación interna y el acceso de consulta externo, por ejemplo:

 

Para asegurarnos que el servidor es capaz de alcanzar las rutas de publicación, con el botón derecho sobre «Certificados revocados» pulsamos «Todas las tareas» -> «Publicar»

 

Comprobar las listas de revocación desde equipo externo

Existe la alternativa de utilizar OCSP para la comprobación de las listas, lo veremos en otro momento.

Cambiar compatibilidad en todas las bases de datos

fernando

Antes o después de ciertas migraciones podemos cambiar el nivel de compatibilidad SQL con el motor instalado. Si desconocemos la versión, podemos obtenerlas con la siguiente consulta:

SELECT SERVERPROPERTY('ProductVersion');

Así como el nivel actual de las bases de datos:

SELECT name, compatibility_level FROM sys.databases;

Para realizar el cambio a todas, excepto las 4 primeras del sistema:

declare @nivel_compatible  varchar(max)
set     @nivel_compatible  = ''
select  @nivel_compatible = @ nivel_compatible +

from   sys.databases
where  database_id > 4 and compatibility_level not in ('100')
exec   (@ nivel_compatible)

En este ejemplo cambiaríamos el nivel de compatibilidad de las que no son 100 a 100, jugando con la clausula WHERE de la instrucción podemos realizar los cambios que necesitemos.

 

Fuente: Diferencias entre niveles de compatibilidad