Growing Innovation - Soluciones a problemas reales
Cuando se estamos utilizando BAM para capturar los datos de los itinerarios en ESB Toolkit 2.0 los datos de las fechas no son guardados correctamente, este Hotfix soluciona este caso puntual en ESB, en el siguiente link podemos ver más detalles:
Por default, el diseñador de itinerarios del ESB Toolkit 2.0 tiene habilitada una encripción por certificados, lo que ocasiona un error cuando se intenta validar o exportar el itinerario, y no se ha seleccionado un certificado. El error que se ve es de este tipo:
Error 1 A X509 Certificate is required in the model property ‘EncryptionCertificate’ to encrypt any sensitive property in the designer.
Para deshabilitar la opción de utilizar el certificado, y poder validar y exportar los itinerarios sin que aparezca este error, se debe hacer lo siguiente:
1. En el directorio de instalación del ESB ir a la siguiente ruta: C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Tools\Itinerary Designer
2. Abrir el archivo ruleset.config
3. Ubicar la sección <property name=”EncryptionCertificate”>
4. Colocar en comentario la primera regla. Se debería ver algo así:
<property name=”EncryptionCertificate”>
<!–<validator type=”Microsoft.Practices.Modeling.Validation.X509CertificateContainerValidator, Microsoft.Practices.Modeling.Validation”
messageTemplate=”A X509 Certificate is required in the model property ‘{0}’ to encrypt any sensitive property in the designer.”
name=”EncryptingCertificate validator”/> –>
<!– Warning message when not enforcing encryption –>
<validator type=”Microsoft.Practices.Modeling.Validation.X509CertificateContainerValidator, Microsoft.Practices.Modeling.Validation”
messageTemplate=”Some data may not be secured because no X509 Certificate was specified in the model property ‘{0}’.”
tag=”Warning”
name=”EncryptingCertificate (warning) validator”/>
</property>
5. Guardar los cambios.
6. Probar nuevamente y el error ya no debe aparecer.
Nota: Si el error pesiste, puede ser necesario cerrar y volver a abrir el Visual Studio.
En días pasados tuve que eliminar el usuario windows con el cual me conectaba a la máquina localmente y crear uno nuevo usuario. Al momento de acceder al SQL Server Management Studio me encontre con la gran sorpresa que mi nuevo usuario de windows ya no tenía acceso.
Aunque mi problema no fue haber olvidado la contraseña del usuario “sa”, los siguientes pasos permiten habilitar a un usuario administrador local para que pueda tener acceso a SQL Server en ausencia del “sa” y posteriormente escoger si modifica la contraseña olvidada del “sa” o por el contrario se queda con la autenticación windows del usuario habilitado.
Prerrequisito:
Pasos:
1.) Parar servicio principal de SQL Server.
2.) Reiniciar el servicio de SQL Server en modo “single user” permitiendo que cualquier usuario que haga parte del grupo de administradores locales se conecte a una instancia de SQL Server como un miembro del rol sysadmin. (Starting SQL Server in Single-User Mode ).
Para ello simplemente abrá una consola y ejecute el siguiente comando:
sqlservr -m –s MSSQLSERVER
El parametro “-m”.habilita el modo “single user” y “-s” simplemente corresponde al nombre del servicio. Tanto la ruta del ejecutable como el nombre del servicio se encuentra en la ventana propiedades del servicio.
3.) Por línea de comando de SQL habilitar el usuario administrador local para que tenga acceso a SQL Server. Para eso abrir otra consola y ingresar el siguiente comando:
sqlcmd -S <NombreMaquina> –E
El parámetro “–S <NombreMaquina>” para especificar el nombre de la instancia de SQL Server a conectarnos y “–E” para establece una conexión de confianza con la misma.
El primer comando sql que se debe ingresar en la linea 1> es:
1> create login [builtin\administrators] from windows;
2> go
El segundo comando sql es:
1> exec sp_addsrvrolemember [<nombreServidor>\UsuarioAdministrador], [sysadmin];
2> go
Y po último cerramos la conexión:
1> shutdown;
2> go
4.) Iniciar el servicio principal de SQL Server
5.) Ingresamos al SQL Server Management Studio con autenticación de Windows con el usuario anteriormente habilitado.
Y sabor !!!! Hemos podido ingresar de nuevo a nuestro SQL Server.
De hay en adelante pueden modificar todas las autenticaciones que crean necesarias e incluso la del “sa”.