El siguiente es el arcvhivo de configuración básica para conectarse desde un cliente OpenVPN hacia un Endian Firewall actuando como servidor OpenVPN

client
dev tap
proto udp
remote <ip servidor openvpn>
resolv-retry infinite
nobind
persist-key
persist-tun
ca <nombre del archivo que contiene el certificado digital>
auth-user-pass
comp-lzo

Sucedió que en un servidor de TS (Terminal Services) un día cualquiera, los nuevos usuarios que iniciaban sesión en escritorio remoto, no se les establecía la impresora por defecto. Al tratar de establecerla manualmente tampoco funcionaba.

Este problema se debe que falta la siguiente llave en el registro de Windows: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows.

Para solucionarlo hay que hacer lo siguiente:

• Desde un equipo que tenga el mismo sistema operativo instalado que el servidor de Terminal Services, copiar el directorio %SystemDrive%\Documents and Settings\Default User al servidor de Terminal Services en la misma ubicación, reemplazando este directorio en el servidor de Terminal Services.
• Eliminar del servidor de Terminal Services los perfiles de usuarios a los que no se les establecía la impresora por defecto y volverlos a crear para corregirles el problema.

Nota:Recuerde que el directorio Default User está oculto por defecto.

Eso es todo. Como apunte personal, sin entrar en detalles, parece que eso del Default User se parece mucho al /etc/skel de Linux

Esta solución y apuntes llegaron de la mano del siguiente KB: http://support.microsoft.com/kb/929270

Tengo un un usuario que usa escritorio remoto para conectarse a la aplicación de gestión comercial de la empresa. Esa aplicación, con este usuario y ejecutando ciertos procesos se bloquea; lo que me obliga a mi como sysadmin a cerrarle la sesión en el Administrador de Servicios de Terminal Server en el servidor cada vez que le sucede esto.

Esta vez y con la ayuda de dos comandos disponibles en Windows 2000 ó superior, me he escrito un batch que le proporcioné al usuario para que desde su equipo cierre su sesión de Terminal Server sin necesidad de mi intervención. Los comandos a saber son qwinsta y rwinsta.

Para comprender mejor como funciona el script aquí van estos datos:

• Servidor de Terminal Services: 192.168.1.21
• Nombre de inicio de sesión del usuario: Cartera

El script es el siguiente:

@echo off
for /f "skip=1 tokens=3" %%i in ('qwinsta Cartera /SERVER:192.168.1.21') do (
    rwinsta /server:192.168.1.21 %%i
)

Fácil, ¿si ó no?

Referencias de ayuda

• Managing Terminal Services Sessions Remotely

Que día, un genio, sin saber (o sabiendo) borró todo el contenido de SYSVOL en el único controlador de dominio de la empresa. No borró SYSVOL exactamente pero si su contenido. Así que cuando íbamos a editar la política por defecto del dominio ó la política por defecto del controlador de dominio, no podíamos.

El problema lo solucionamos ejecutando el siguiente comando en el controlador de dominio:

dcgpofix.exe

Afortunadamente se trataba de un dominio pequeño en donde la única necesidad que teníamos era poder darle permisos de inicio de sesión en Terminal Server a varios usuarios

Eso es todo

Un caso que suele a parecer alguna vez, es el del usuario que tiene una conexión VPN PPTP configurada en Windows XP para conectarse a la empresa. Sabemos que Windows XP no es capaz de iniciar una conexión VPN antes de que el usuario inicie sesión en el dominio por lo que en algunas ocasiones, cuando el usuario trata de iniciar remotamente la sesión en el dominio, se genera un mensaje de error diciendo que no es posible iniciar sesión porque no hay controladores de dominio disponibles para atender la solicitud de inicio de sesión.

Para solucionar este problema es necesario iniciar la conexión VPN antes de que el usuario solicite el inicio de sesión, de tal manera que se establezca el canal de comunicaciones con los servidores controladores de dominio de la empresa para atender oportunamente el inicio remoto de sesión en el dominio. La solución nos llega de la mano de Windows Server 2003 Resource Kit Tools

Pasos:

La película esta vez va con este tema, ya que el escenario de recuperación de Buzones de Exchange Server 2007 lo tenía así.

• Se necesita recuperar el buzón del usuario Pepito Perez Perez (pperez@midominio.com) en un nuevo buzón llamado RestoreMBox (restorembox@midominio.com). Se tiene una copia de la base de datos de Microsoft Exchange Server antes de la pérdida del buzón del usuario Pepito Perez Perez.


• Primer paso: Crear un Grupo de Almacenamiento de Recuperación en el servidor Microsoft Exchange Server. Referencia de apoyo: http://goo.gl/HwTSM.


• Segundo paso: Restaurar la copia de seguridad de la base de datos de Microsoft Exchange Server a la ubicación del Grupo de Almacenamiento de Recuperación. Usar la misma referencia de apoyo del punto anterior.


• Tercer paso: Montar la base de datos del Grupo de Almacenamiento de Recuperación. Suponiendo que no contiene etrrores y está en estado "Clean Shutdown", de lo contrario, usar la misma consola de recuperación de desastres de Microsoft Exchange Server para corregir los problemas en esta base de datos.


• Cuarto paso: Abrir el shell de Administración de Exchange (PowerShell) y ejecutar lo siguiente (Estoy ejecutando esto como Administrador del Dominio).

  Add-MailboxPermission -Identity restorembox -User Administrador -AccessRights FullAccess
  
  Restore-Mailbox -RSGMailBox "Pepito Perez Perez" -RSGDatabase "GrupoRecuperacion\Mailbox Database"
  -Identity restorembox -TargetFolder restorembox
  

También se puede usar el atributo msExchMailboxGuid para identificar el buzón fuente o el buzón destino. Por ejemplo.

Este truco me tocó hacerlo para una consulta en un generador de reportes. Se trata de agregar filas vacías al resultado de una consulta SELECT. ¿Para qué? Pués a mi me tocó hacerlo para ajustar el desplazamiento de la impresora en el generador de reportes Report Manager

SELECT column1, column2, column3 FROM table
UNION ALL 
SELECT null, null, null (un NULL por cada columna seleccionada en el primer SELECT) 
ORDER BY column1

• Dominio de Active Directory: midominio.local
• Nombre del servidor controlador de dominio: atlas
• Dirección IP del controlador de dominio: 10.10.0.1

Archivo /etc/squid.conf

auth_param ntlm program /usr/lib/squid/ntlm_auth midominio.local/atlas
auth_param ntlm children 5
auth_param ntlm keep_alive on
.
.
.
acl MI_LAN src 10.10.0.0/255.255.0.0
acl USUARIOS_LAN proxy_auth REQUIRED
.
.
.
http_access allow MI_LAN USUARIOS_LAN

Archivo /etc/hosts

...
10.10.0.1        atlas.midominio.local        atlas
...

Hasta este punto no había problemas si se trabata de un controlador de dominio en Windows 2000 Server ó Windows Server 2003 con clientes basados en Windows XP. No hay que hacer nada más si cuento con estos controladores de dominio.

El asunto se enredó cuando llegó Windows Server 2008 con clientes basados en Windows Vista, Windows 7 y por supuesto Windows XP. Para este escenario hacer lo descrito a continuación

En el controlador de dominio de Windows Server 2008

En el editor de políticas de grupo (Inicio | Ejecutar | gpmc.msc). Habilitar la siguiente directiva:

+Configuración del equipo
|-Directivas
 |-Configuración de Windows
  |-Configuración de seguridad
   |-Directivas locales
    |-Opciones de seguridad
      Seguridad de red: nivel de autenticación de LAN Manager = Enviar respuestas LM y NTLM

ó también...

      Seguridad de red: nivel de autenticación de LAN Manager = Enviar LM y NTLM: Usar la seguridad de sesión NTLMv2 si se negocia      

En los clientes Windows Vista ó Windows 7