Archivado en Febrero, 2010

Numero de licencias con Key Management Service (KMS)

27 Febrero, 2010

kms1 300x81 Numero de licencias con Key Management Service (KMS)

Control de licencias con Key Management Service

Como ya sabes y no procede explicar en este artículo es lo que hace el servicio KMS de Microsoft, sólo vamos a hacer una breve explicación del servicio y nos vamos a centrar en su funcionamiento y como controlar dichas licencias sabiendo el número que debemos reportar y conociendo las versiones de cada uno de los sistemas operativos que se registran en KMS.

Este artículo no explica como se monta el servicio KMS, está orientado a explicar el método por el que vamos a contabilizar las licencias y como funciona internamente dicho servicio.

Este texto se basa principalmente en la experiencia de utilización del servicio y en la necesidad de desarrollar una herramienta para poder contabilizar dichas máquinas sin tener que tener sistemas complejos como System Center Configuration manger ( SCCM ) o System Center Operation Manager (SCOM) para realizar estas funciones, las cuales, requieren una licencia y un agente en cada servidor, algo realmente caro.

Muchas veces es imposible instalar agentes cuando tú organización tiene un número de máquinas muy grande.

Sigue leyendo pulsando para continuar en leer más …

» Leer más: Numero de licencias con Key Management Service (KMS)

Filtros de seguridad en Directorio Activo para GPOs

25 Febrero, 2010

Imagína que tenemos una política aplicada y queremos que dicha política no se aplique a determinadas máquinas, por lo que necesitamos hacer un filtro y luego aplicar ese filtro de manera que a determinadas máquinas o usuarios no se les aplique.

En primer lugar creamos un grupo por ejemplo: excepcion_Standart_de_GPO1

Tenemos que meter en este grupo las máquinas o usuarios que queremos excluir en la aplicación de la política. Por lo tanto es a nivel de política de dominio, por lo que vamos a trabajar sobre esta:

default policy 259x300 Filtros de seguridad en Directorio Activo para GPOs

Ahora sobre la GPO de dominio nos vamos a la pestaña “Delegation” aquí damos al botón abajo a la derecha “Avanzadas” y agregamos el grupo que hemos creado. Marcaremos el check “Denegar” para la entrada de seguridad “Apply group Policy”.

denegar delegar 300x163 Filtros de seguridad en Directorio Activo para GPOs

La configuración de dengación es más restrictiva que la de lectura, es decir, que aunque haya un grupo en la pestaña “delegation” que permita aplicar la política a las máquinas, al existir uno más restrictivo, el resultado será DENEGACIÓN.

IvanZito

Loopback Policies. Control de políticas locales

25 Febrero, 2010

Muchas veces nos encontramos en la obligación de tener que cambiar políticas locales de las máquinas y además tenemos que controlar estas desde el dominio, para que cuando un usuario no esté conectado al dominio  un portátil tenga una configuración especial.

Vamos a realizar un ejemplo típico donde nuestro usuario  está con el portátil desconectado e inicia sesión con su portátil, aquí se le muestra un fondo de escritorio que no es corporativo y nuestro usuario da una imagen ante nuestros clientes poco corporativa.

Deseamos que cuando utilice su portátil y no esté conectado al dominio, su escritorio no pueda tener ningún wallpapers o tenga uno corporativo.

Lo primero que hay que hacer es un grupo donde alberguemos todas las máquinas del departamento o por ejemplo como hemos realizado a continuación, meter todos los portátiles del departamento finanzas:

grupo 300x166 Loopback Policies. Control de políticas locales

Una vez que tenemos nuestro grupo preparado. Debemos crear la política que luego vamos a utilizar, para ello en el administrador de políticas GPMC creamos una nueva política para forzar el escritorio del usuario que queramos:

politica desktop 300x239 Loopback Policies. Control de políticas locales

Para nuestra configuración es necesario no sólo configurar la política del escritorio, tenemos que configurar una política llamada: “User Group Policy loopback Proccesing Mode”. Esta política hace que se haga un “merge” (una fusión) de la política de dominio con las políticas locales. Realizándose una mezcla de los dos scopes: Dominio y Local

loopback desktop 300x250 Loopback Policies. Control de políticas locales

La explicación de las opciones de la política sería la siguiente:

Replace: La configuración definida por el usuario en su máquina en los objetos de política o en su Shell, reemplaza la configuración de políticas que nosotros estamos aplicando en el dominio o las que normalmente se le aplica. Esto quiere decir que vale más lo que el usuario haya configurado que nuestra política de dominio.

Merge: La configuración final del usuario es una fusión de las políticas locales y las políticas de dominio. Cuando el usuario no está logado en el dominio se realiza la fusión o “merge” de dichas políticas. Si hay conflicto en las políticas  se aplica la configuración del usuario.

Este tipo de política se aplicará a cualquier usuario que haga logon en la máquina.

Configurarémos entonces: “User Group Policy loopback Proccesing Mode

Ahora asigna tú política a la OU donde están las máquinas o la unidad organizativa donde están las máquinas a las que quieres aplicar la política y abajo en Scope, selecciona el grupo que has creado con los portátiles, así sólo se aplicará a las máquinas del grupo y no a los demás:

scope sales 300x175 Loopback Policies. Control de políticas locales

IvanZito

Una vez que tenemos nuestro grupo preparado. Debemos crear la política que luego vamos a utilizar, para ello en el administrador de políticas GPMC creamos una nueva política para forzar el escritorio del usuario que queramos:

Asociar usuarios a login en SQL Server al restaurar

22 Febrero, 2010

Cuando importas una base de datos en un SQL Server, se crean automáticamente los usuarios de la base de datos.

Es de obligación crear de forma manual los login en la base de datos para que los usuarios externos o las aplicaciones puedan acceder al motor de la base de datos e inmediatamente vincular la base de datos que van a utilizar para su utilización.

Nos encontramos el problema de que los Login, no están asociados a la bbdd que acabamos de restaurar ya que el esquema que has importado es diferente al que estamos utilizando para actualizar el esquema y asociar los login a los usuarios de la bases de datos modificando el nombre de los objetos de la bbdd, puedes hacerlo de una forma sencilla para no tener que hacerlo desde el SQL Management Studio de uno en uno.

Aclaremos que no es lo mismo un Login de SQL que un usuario de BBDD.

El login: te permite acceder al motor de la bbdd y ver las bases de datos, pero no puedes entrar en ellas a no ser que tengas usuarios en las bbdd y el login esté vinculado con ese usuario.

Un usuario de BBDD: Debes de tener un login previo si quieres acceder a la bbdd.

Para saber que usuarios de la bbdd no tiene login asociado, tienes que hacer la siguiente select sobre la bbdd que acabamos de restaurar o bien, sobre las que quieres verificar:

EXEC sp_change_users_login ‘Report’

Una vez que sabemos cuales son los usuarios que no están vinculados, podemos ejecutar la siguinte consulta por cada uno de los usuarios:

EXEC sp_change_users_login ‘Auto_Fix’, ‘user’

Borrar planes de mantenimiento SQL 2005

22 Febrero, 2010

!!! NO PODEMOS BORRAR LOS PLANES DE MANTENIMIENTO !!!

Algunas veces nos ocurre que no es posible borrar planes de mantenimiento en una base de datos  SQL Server 2005 desde el SQL Server Management Studio, el error normalmente es porque has creado los planes de mantenimiento con un usuario y luego estás intentando borrar con otros, esto hace que nos tegamos permisos sysadmin  sobre un procedimiento que es el que se lanza al intentar borrar dicho plan con el botón derecho.

Dicho procedimiento están en la bbdd ( msdb ) y la tabla se llama:

dbo.sp_delete_maintenance_plan

Los planes de mantenimiento guardan relación en 4 tablas:

  • sysmaintplan_plans ( cabecera de los planes )
  • sysmaintplan_log
  • sysmaintplan_subplans
  • sysmaintplan_plans

Dentro de la tabla sysmaintplan_plans podemos ver los IDs  de los planes de mantenimiento que tenemos configurados en la bbdd.

————–   PROCEDEMOS —————————————————–

1.- Identificar nuestro plan de mantenimiento

–  select * from sysmaintplan_plans

sql1 300x60 Borrar planes de mantenimiento SQL 2005

Ahora podemos  IDentificar el plan que queremos borrar y saber entonces cual es el número que identifica unicamente el plan de mantenimiento. Bien,  pues ahora podemos borrar dicho plan y las relaciones en otras tablas.

2.- Borrar relaciones las tablas secundarias y luego el registro de la tabla sysmaintplan_plans

Procede de la siguiente forma:

delete from sysmaintplan_log where plan_id = ‘2400B15A-3135-4D25-B14A-78A2568B4D20′

delete from sysmaintplan_subplans where plan_id = ‘2400B15A-3135-4D25-B14A-78A2568B4D20′

– delete from sysmaintplan_plans where id = ‘2400B15A-3135-4D25-B14A-78A2568B4D20′

3.- Borra los jobs de forma manual desde el SQL Management Studio

Una vez borradas las relaciones desde el SQl Management Studio borrar con el botón derecho los Jobs que eran del plan que hemos borrado.



-->