LATAM Team blog

SMTP Protocol log en Exchange 2007

Por Daniel Seveso

 

El "SMTP protocol log" es de suma utilidad para el seguimiento de problemas de trasporte de mensajes. El mismo registra la conversación a nivel del protocolo smtp, respuestas y errores generados por los participantes de esta conversación.

En Exchange 2000 y 2003, podemos aumentar el nivel de diagnóstico del servicio MSExchangeTransport en la categoría SMTP Protocol a nivel de debug, obteniendo así un registro de la actividad de SMTP en forma de eventos en el Application log.

 

Esto se logra configurando el valor 7 en el siguiente clave de registry:

HKLM\System\CurrentControlSet\Services\MSExchangeTransport\Diagnostics
Type: REG_DWORD
Value name: 6 SMTP Protocol
Value: 7

 

Luego de configurada esta opción, cuando recibimos un mensaje a través de SMTP, el application log muestra eventos informativos 7006 indicando que tipo de comandos estan siendo procesados y cual es la respuesta del servidor a cada comando. Este es un ejemplo del mensaje de conexión luego del ehlo recibido por el server.

Event Type: Information
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 7006
Date: 5/1/2008
Time: 6:15:18 PM
User: N/A
Computer: NETE2K3FE
Description:
This is an SMTP protocol log for virtual server ID 1, connection #1. The client at "192.168.131.160" sent a "ehlo" command, and the SMTP server responded with "250-NetE2K3FE.dseveso.net Hello [192.168.131.160] 250-TURN 250-SIZE 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-TLS 250-STARTTLS 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50 250 OK ". The full command sent was "ehlo NetDC1.dseveso.net". This is an informational event and does not indicate an error.

 

Adicionalmente a estos eventos, disponemos también la opción de generar un archivo de log (protocol log), configurandolo dentro de las opciones del SMTP Virtual Server marcando la opción "Enable Logging"

 

Con "Properties..." puedes definir cuales son los campos a registrar. Desde el más básico:

#Fields: time c-ip cs-method cs-uri-stem sc-status
23:15:18 192.168.131.160 EHLO - 250
23:15:18 192.168.131.160 MAIL - 250
23:15:18 192.168.131.160 RCPT - 250
23:15:18 192.168.131.160 RCPT - 250
23:15:18 192.168.131.160 RCPT - 250
23:15:19 192.168.131.160 BDAT - 250
23:15:19 192.168.131.160 QUIT - 240

 

Hasta el más completo conjunto de campos.

#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken cs-version cs-host cs(User-Agent) cs(Cookie) cs(Referer)
2008-05-01 23:29:34 192.168.131.160 NetDC1.dseveso.net SMTPSVC1 NETE2K3FE 192.168.131.163 0 EHLO - +NetDC1.dseveso.net 250 0 339 23 0 SMTP - - - -
2008-05-01 23:29:34 192.168.131.160 NetDC1.dseveso.net SMTPSVC1 NETE2K3FE 192.168.131.163 0 MAIL - +FROM:<user@test.com> 250 0 38 25 0 SMTP - - - -
2008-05-01 23:29:34 192.168.131.160 NetDC1.dseveso.net SMTPSVC1 NETE2K3FE 192.168.131.163 0 RCPT - +TO:<test1@dseveso.net> 250 0 30 27 0 SMTP - - - -
2008-05-01 23:29:34 192.168.131.160 NetDC1.dseveso.net SMTPSVC1 NETE2K3FE 192.168.131.163 0 RCPT - +TO:<test2@dseveso.net> 250 0 30 27 0 SMTP - - - -
2008-05-01 23:29:34 192.168.131.160 NetDC1.dseveso.net SMTPSVC1 NETE2K3FE 192.168.131.163 0 RCPT - +TO:<test3@dseveso.net> 250 0 30 27 0 SMTP - - - -
2008-05-01 23:29:34 192.168.131.160 NetDC1.dseveso.net SMTPSVC1 NETE2K3FE 192.168.131.163 0 BDAT - +<91E79368A3574A6983259092E1BE3BFC@dseveso.net> 250 0 84 1015 311 SMTP - - - -
2008-05-01 23:29:34 192.168.131.160 NetDC1.dseveso.net SMTPSVC1 NETE2K3FE 192.168.131.163 0 QUIT - NetDC1.dseveso.net 240 471 70 4 0 SMTP - - - -

 

Cambios en Exchange 2007

En Exchange 2007 la funcionalidad de registrar eventos de SMTP en el Aplication Log no está disponible. Sin embargo, la información que nos provee el Protocol Log de Exchange 2007 supera en calidad y cantidad la ofrecida por ambos logs en Exchange 2000/2003. El Protocol Log en Exchange 2007 incluye información de sesión, conector asociado, número de secuencia de eventos para cada sesión smtp, y una serie de caracteres especiales indicando la dirección del evento. Este es un ejemplo de la entrega del mismo mensaje de arriba pero en un Exchange 2007.

#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context
2008-05-01T23:42:35.126Z,NETE12-1\Default NETE12-1,08CA79F858031A16,0,192.168.131.162:25,192.168.131.163:1366,+,,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,1,192.168.131.162:25,192.168.131.163:1366,*,None,Set Session Permissions
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,2,192.168.131.162:25,192.168.131.163:1366,>,"220 NetE12-1.dseveso.net Microsoft ESMTP MAIL Service ready at Thu, 1 May 2008 18:42:34 -0500",
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,3,192.168.131.162:25,192.168.131.163:1366,<,EHLO NetE2K3FE.dseveso.net,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,4,192.168.131.162:25,192.168.131.163:1366,>,250-NetE12-1.dseveso.net Hello [192.168.131.163],
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,5,192.168.131.162:25,192.168.131.163:1366,>,250-SIZE,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,6,192.168.131.162:25,192.168.131.163:1366,>,250-PIPELINING,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,7,192.168.131.162:25,192.168.131.163:1366,>,250-DSN,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,8,192.168.131.162:25,192.168.131.163:1366,>,250-ENHANCEDSTATUSCODES,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,9,192.168.131.162:25,192.168.131.163:1366,>,250-STARTTLS,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,10,192.168.131.162:25,192.168.131.163:1366,>,250-X-ANONYMOUSTLS,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,11,192.168.131.162:25,192.168.131.163:1366,>,250-AUTH NTLM,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,12,192.168.131.162:25,192.168.131.163:1366,>,250-X-EXPS GSSAPI NTLM,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,13,192.168.131.162:25,192.168.131.163:1366,>,250-8BITMIME,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,14,192.168.131.162:25,192.168.131.163:1366,>,250-BINARYMIME,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,15,192.168.131.162:25,192.168.131.163:1366,>,250-CHUNKING,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,16,192.168.131.162:25,192.168.131.163:1366,>,250-XEXCH50,
2008-05-01T23:42:35.206Z,NETE12-1\Default NETE12-1,08CA79F858031A16,17,192.168.131.162:25,192.168.131.163:1366,>,250 XRDST,
2008-05-01T23:42:35.216Z,NETE12-1\Default NETE12-1,08CA79F858031A16,18,192.168.131.162:25,192.168.131.163:1366,<,X-EXPS GSSAPI,
2008-05-01T23:42:35.216Z,NETE12-1\Default NETE12-1,08CA79F858031A16,19,192.168.131.162:25,192.168.131.163:1366,>,334 <authentication response>,
2008-05-01T23:42:35.226Z,NETE12-1\Default NETE12-1,08CA79F858031A16,20,192.168.131.162:25,192.168.131.163:1366,>,334 <authentication response>,
2008-05-01T23:42:35.226Z,NETE12-1\Default NETE12-1,08CA79F858031A16,21,192.168.131.162:25,192.168.131.163:1366,*,SMTPSubmit SMTPSubmitForMLS SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPSendEXCH50 SMTPAcceptEXCH50 AcceptRoutingHeaders SendRoutingHeaders SendForestHeaders SendOrganizationHeaders SendAs,Set Session Permissions
2008-05-01T23:42:35.226Z,NETE12-1\Default NETE12-1,08CA79F858031A16,22,192.168.131.162:25,192.168.131.163:1366,*,DSEVESONET\NETE2K3FE$,authenticated
2008-05-01T23:42:35.226Z,NETE12-1\Default NETE12-1,08CA79F858031A16,23,192.168.131.162:25,192.168.131.163:1366,>,235 2.7.0 Authentication successful,
2008-05-01T23:42:35.226Z,NETE12-1\Default NETE12-1,08CA79F858031A16,24,192.168.131.162:25,192.168.131.163:1366,<,MAIL FROM:<user@test.com> AUTH=<>,
2008-05-01T23:42:35.226Z,NETE12-1\Default NETE12-1,08CA79F858031A16,25,192.168.131.162:25,192.168.131.163:1366,*,08CA79F858031A16;2008-05-01T23:42:35.126Z;1,receiving message
2008-05-01T23:42:35.226Z,NETE12-1\Default NETE12-1,08CA79F858031A16,26,192.168.131.162:25,192.168.131.163:1366,>,250 2.1.0 Sender OK,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,27,192.168.131.162:25,192.168.131.163:1366,<,RCPT TO:<test1@dseveso.net>,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,28,192.168.131.162:25,192.168.131.163:1366,>,250 2.1.5 Recipient OK,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,29,192.168.131.162:25,192.168.131.163:1366,<,RCPT TO:<Test2@dseveso.net>,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,30,192.168.131.162:25,192.168.131.163:1366,>,250 2.1.5 Recipient OK,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,31,192.168.131.162:25,192.168.131.163:1366,<,XEXCH50 1080 3,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,32,192.168.131.162:25,192.168.131.163:1366,>,354 Send binary data,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,33,192.168.131.162:25,192.168.131.163:1366,>,250 2.0.0 XEXCH50 OK,
2008-05-01T23:42:35.236Z,NETE12-1\Default NETE12-1,08CA79F858031A16,34,192.168.131.162:25,192.168.131.163:1366,<,BDAT 1154 LAST,
2008-05-01T23:42:35.587Z,NETE12-1\Default NETE12-1,08CA79F858031A16,35,192.168.131.162:25,192.168.131.163:1366,>,250 2.6.0 <1E05BED233AB42D4AB2689A7385E0437@dseveso.net> Queued mail for delivery,
2008-05-01T23:42:35.597Z,NETE12-1\Default NETE12-1,08CA79F858031A16,36,192.168.131.162:25,192.168.131.163:1366,<,QUIT,
2008-05-01T23:42:35.597Z,NETE12-1\Default NETE12-1,08CA79F858031A16,37,192.168.131.162:25,192.168.131.163:1366,>,221 2.0.0 Service closing transmission channel,
2008-05-01T23:42:35.597Z,NETE12-1\Default NETE12-1,08CA79F858031A16,38,192.168.131.162:25,192.168.131.163:1366,-,,Local

 

El campo "event" determina el tipo de evento en la conversación, y su simbología indica lo siguiente:

+   Connect
-   Disconnect
>   Send
<   Receive
*   Information

 

El campo "session-id" y "sequence-number" nos permite filtrar los eventos del protocol log por una determinada conversación smtp y ordenar los eventos tal como son recibidos por el servidor. Esto es útil a la hora de individualizar las conversaciones simultáneas de SMTP que se mantienen con múltiples servidores. 

Debido a la gran cantidad de información que se registra en este log, el mismo se encuentra deshabilitado en forma estándar. Tienes que habilitarlo y configurarlo desde el shell.

A diferencia del resto de los logs de transporte que se habilitan y configuran en el objeto TransportServer, el protocol log se habilita para cada Receive Connector o SendConnector en forma independiente y se configura a nivel general en el TransportServer.  Solo el send connector que representa el servicio de smtp usado internamente entre servidores de Exchange, se habilita a nivel del TransportServer.

 

Para habilitar el protocol log en mi receive connector NETE12-1\Default NETE12-1, el comando es el siguiente:

[PS] C:\>Set-ReceiveConnector "NETE12-1\Default NETE12-1" -ProtocolLoggingLevel:Verbose

siendo NETE12-1\Default NETE12-1 la identidad del ReceiveConnector.

 

Para habilitar el protocol log en el send connector interno, el comando sería el sigiuente:

[PS] C:\>Set-TransportServer NETE12-1 -IntraOrgConnectorProtocolLoggingLevel:Verbose

siendo NETE12-1 el TransportServer (servidor con rol de HUB)

 

Los archivos de log se guardan en forma estándar en

<Directorio de instalación de Exchange>\TransportRoles\Logs\ProtocolLog\

 

Las opciones por omisión del protocol log para todas sus instancias, son las siguientes y pueden ser cambiadas usando el comando Set-TransportServer con la opción correspondiente:

ReceiveProtocolLogMaxAge : 30.00:00:00  (30 días)
ReceiveProtocolLogMaxDirectorySize : 250MB
ReceiveProtocolLogMaxFileSize : 10MB
ReceiveProtocolLogPath : C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive

SendProtocolLogMaxAge : 30.00:00:00
SendProtocolLogMaxDirectorySize : 250MB
SendProtocolLogMaxFileSize : 10MB
SendProtocolLogPath : C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpSend

Puedes obtener información completa de como administrar el protocol log en Exchange 2007 visitando el siguiente sitio de Technet

 

CLUSTER NODE JOIN ERROR 0x80041013

Alessandro Gonçalves

O procedimento de agregar um nó no cluster é normalmente simples e sem percalços. Todavia esse se tornou interessante pois revela um pouco da complexidade agregada a operações rotineiras. Apenas quando enfrentamos um problema que percebemos o quanto devemos estudar para compreender o produto que trabalhamos.

Esse incidente em particular , envolveu a adição de um quinto nó em um cluster já em produção há meses.

Vamos iniciar por coletar o cluster log. Também podemos coletar o report do wizard do cluadmin , pois esse irá também mostrar o erro no procedimento de juntar o nó no cluster.

CLUSTER.LOG

****************************************************

2007-08-01 13:01:57.713 [ERR ] node101: The query for information about the network connection "Broadcom NetXtreme Gigabit Ethernet Adapter - Onboard - Link A" failed. (hr=0x80041013, {B64DC7A2-444D-422D-BF6A-5C9162B45C50}, {088D6F8B-CCD4-4D0C-9BBD-9C2C730B00FB}, 1, 1, 1), Cluster configuration cannot continue. The Windows Management Instrumentation (WMI) query (to locate the network connection on this node) has failed. Stop and restart the Windows Management Instrumentation (winmgmt) service on this node and try again. If the problem persists, reboot this node and try again.

2007-08-01 13:01:57.916 [INFO] FVDAT100: (null) (hr=00000000, {FDC75680-7DBB-42CA-8003-E4CDB01FF062}, {B8453B8F-92FD-4350-A6D9-551FD018B791}, 0, 90, 5), (null

Ao analisar o log do cluster percebemos que a falha ocorre ao pesquisar a interface de rede no WMI .

2007-08-01 13:01:58.728 [ERR ] FVDAT100: Could not contact the cluster. (hr=0x80041013, {B8453B8F-92FD-4350-A6D9-551FD018B791}, {2E305DD0-9DCA-47FE-8CF6-4306CA72C4A2}, 1, 1, 1), (null)

*****************************************************

O interessante que a pesquisa está sendo feita contra o servidor 101 (que é o primeiro nó do cluster).

Para descobrir mais sobre o erro 0x80041013 , utilizo sempre a ferramenta  Error Lookup Tool e ela nos traz:

# for hex 0x80041013 / decimal -2147217389 :

  WBEM_E_PROVIDER_LOAD_FAILURE                                  wbemcli.h

# 1 matches found for "0x80041013"

O erro deixa claro que não conseguimos carregar um provider .

Um comportamento que normalmente verifico quando temos esse erro com as NIC é que as mesmas não se registram no MSINFO32 , ou seja abaixo de Hardware \ Components \ Network \ Adapter não há nenhuma informação das placas de rede , indicando um problema com a WMI deste componente.

Ao rodar o msinfo32 em todos os nós do cluster , verifiquei que nenhum apresentava informações da NIC .

Para confirmar o problema com o provider e também investigar que não existe nenhum mais alguma coisa com o WMI, utilizo o WMIDiag que além de informar também aponta alternativas para consertar problemas.

Aqui está o report gerado pelo WMIDiag:

*****************************************************

37997 12:28:03 (0) ** - ROOT/CIMV2, BRCMGroup ({3D888674-29E1-4C0A-BB3D-7F3DD69F71CB})
37998 12:28:04 (0) ** Provider DLL: `WMI information not available (This could be the case for an external application or a third party WMI provider)`
37999 12:28:04 (0) ** => This is an issue because there are still some WMI classes referencing this list of providers
38000 12:28:04 (0) ** while the DCOM registration is wrong or missing. This can be due to:
38001 12:28:04 (0) ** - a de-installation of the software.
38002 12:28:04 (0) ** - a deletion of some registry key data.
38003 12:28:04 (0) ** - a registry corruption.
38004 12:28:04 (0) ** => You can correct the DCOM configuration by:
38005 12:28:04 (0) ** - Executing the `REGSVR32.EXE ` command.
38006 12:28:04 (0) ** Note: You can build a list of classes in relation with their WMI provider and MOF file with WMIDiag.
38007 12:28:04 (0) ** (This list can be built on a similar and working WMI Windows installation)
38008 12:28:04 (0) ** The following command line must be used:
38009 12:28:04 (0) ** i.e. `WMIDiag CorrelateClassAndProvider`
38010 12:28:04 (2) !! WARNING: Re-registering with REGSVR32.EXE all DLL from `C:\WINDOWS\SYSTEM32\WBEM\`
38011 12:28:04 (0) ** may not solve the problem as the DLL supporting the WMI class(es)
38012 12:28:04 (0) ** can be located in a different folder.
38013 12:28:04 (0) ** You must refer to the class name to determine the software delivering the related DLL.
38014 12:28:04 (0) ** => If the software has been de-installed intentionally, then this information must be
38015 12:28:04 (0) ** removed from the WMI repository. You can use the `WMIC.EXE` command to remove
38016 12:28:04 (0) ** the provider registration data.
38017 12:28:04 (0) ** i.e. `WMIC.EXE /NAMESPACE:\\ROOT\CIMV2 path __Win32Provider Where Name=`BRCMGroup` DELETE`
38018 12:28:04 (0) ** => If the namespace was ENTIRELY dedicated to the intentionally de-installed software,
38019 12:28:04 (0) ** the namespace and ALL its content can be ENTIRELY deleted.
38020 12:28:04 (0) ** i.e. `WMIC.EXE /NAMESPACE:\\ROOT path __NAMESPACE Where Name=`CIMV2` DELETE`
38021 12:28:04 (0) ** - Re-installing the software.

**************************************************************

A partir do report ficou claro que teríamos que registrar o WMI provider de alguma maneira.

Comecei por reinstalar os drivers e utilitários do fabricante , o que não surtiu nenhum efeito.

Nesse ponto extrai os drivers para um diretório ; normalmente setup.exe /a ; verifiquei que existia uma pasta chamada \WMI , com os arquivos MOF e DLL utilizados para o registrar os providers WMI.

Nesse ponto , necessitamos registrar os providers.

Abra a linha de comando e certifique que o caminho está no diretório WMI que contém os arquivos e executei os comandos.

for %i in (*.dll) do RegSvr32 - s %i
for %i in (*.exe) do RegSvr32 - s %i

Após um reinício nos servidores as propriedades da NIC estavam apresentadas no system information e a operação de agregar o nó do cluster foi completada com sucesso.

Isso mostra que existe vários aspectos "under the hood" e qualquer operação , por mais trivial que ela seja. Mas com princípios básicos de resolução de problemas a nossa possibilidade de sucesso aumenta consideravelmente.

Lidiando con la encriptación de hoy

 

Por Daniel Seveso

Tuve un caso hace unos días, donde necesitaba averiguar la conversación LDAP entre un servidor Exchange 2007 y un controlador de dominio Windows.

En los días de Exchange 5.5 y Windows 2000, todo lo que se necesitaba era una captura de red en el cliente de LDAP, y analizar lo que se veía en el tráfico correspondiente al puerto 389.

Luego se incorpora LDAP signing que encripta y firma el tráfico LDAP de forma de proteger el contenido de información, luego IPSec como una capa más de encriptación y como si fuera poco TCP offloading embebido ahora en Windows 2003 SP2 y las nuevas tarjetas de red. Todo esto puede reducir lo que vemos en una captura de tráfico a los tres paquetes iniciales de la conversación TCP/IP, o lo que se denomina "Three way handshake".

Un colega me sugirió usar esta herramienta que es lo que quiero destacar en este post, por ser de gran utilidad para evitar nuestro mundo encriptado.

AD Insight, se conecta al cliente ldap de cualquier máquina 32-bit (wldap32.dll) y reporta, al mejor estilo FileMon o RegMon, toda la actividad LDAP generada por ese cliente. Esto incluye obviamente los datos enviados, respuestas del servidor y cualquier error que haya en la comunicación LDAP. (por supuesto esto no nos sirve para investigar problemas de red, sino para investigar problemas de LDAP).

AD Insight muestra el nombre del proceso, el puerto que genera la conexión, el tipo de requerimiento, la cuenta que se está usando para realizar el query y el DC al que se está efectuando la consulta.

Tiene un asistente para localizar problemas, indica el tiempo que toma determinada búsqueda y la lista completa de argumentos para cada query.

Aquí hay un ejemplo de la interfaz gráfica para que tengan una idea.

Lo mejor de esta herramienta: Es de Sysinternals, o sea, ahora de Microsoft. Puedes bajarla en forma gratuita de http://technet.microsoft.com/en-us/sysinternals/bb897539.aspx

Algunas restricciones: Solo funciona en 32-bit. He logrado usarla en Virtual PC deteniendo el servicio de Virtual Machine Additions, pero la experiencia en VPC fue bastante inestable.

Enjoy!

 

Daylight Saving Time change in Chile – Effects on Outlook clients and Exchange Servers

Background

The government of Chile announced last February 07^th 2008, that their current daylight saving time will be extended in order to save energy. The new fall back date for the daylight saving period of 2007-2008 is:

§ Daylight saving time ends:  Saturday, March 29^th, 2008 11:59:59 PM

Currently, computers in Chile use the “(GMT-04:00) Santiago” time zone setting. The default configuration for this time zone setting in Windows Operating Systems does not reflect the new final date for the daylight saving time defined by the government.

After you have updated the “(GMT-04:00) Santiago”  on your Operating System, Microsoft Outlook calendars will display items 1 hour ahead their actual time during the “Delta” period (defined between March 9^th 2008 and March 29^th 2008). 

Please see the article on how to implement the new time zone on Windows Operating Systems.

What can I do to fix my appointments?

Users located in Chile can choose different ways to update the calendar items in the delta period:

• Manually modify each appointment after the operating system time zone has been updated. 

• Outlook users can use “Time Zone Data Update Tool for Microsoft Outlook” on local computers to fix the appointments during the delta period.
  
• Exchange Administrators can use the “Microsoft Exchange Calendar Update Configuration Tool” to fix the appointments during the delta period. Running this tool is a complex procedure, recommended only for organizations for which the manual update or Outlook tool is not suitable.

The examples below are not a step by step guide, but just an example about running the tools in a particular environment. These examples will give you an idea of what it takes to run the tools and evaluate your own method.  You will need to understand all the variables for your environment by reading the appropriate documentation for the tools you will use.

 

Manually Moving Calendar Items

This option is recommended for users or organizations that have a few appointments during the delta period and the impact of having those incorrect is low.

This option avoids the risk and complexity that is associated with running the Outlook or Exchange tools. In contrast, you must make an additional educational effort to lessen confusion for users.

In this case the appointments created before applying the DST update to the operating system that fall into the delta period should be manually moved to the correct time (one hour less). This change should be done after applying the DST update to the operating system. Users should move only their own calendar items and meeting requests. (i.e. users should not move meeting requests accepted from other users).

After moving a meeting request the user should “Send Updates” to the attendees when this dialog is presented.

 

See Additional Recommendations later in this post

Using “Time Zone Data Update Tool for Microsoft Outlook”

This option consists of distributing the “Time Zone Data Update Tool for Microsoft Outlook” to the clients in order to update their calendar items during the delta period.  The following article explains how to download and use this tool.

931667 How to address time zone changes by using the Time Zone Data Update Tool for Microsoft Office Outlook

This option avoids the risk that is associated with running the Exchange tool. In contrast, it is difficult to guarantee that all users will run the Outlook tool correctly and in a timely manner. Users who do not have Outlook (i.e. OWA only users) will be unable to run the Outlook tool. You must make an educational effort to lessen confusion for users.

The following is an example of how to run the Time Zone Data Update Tool for Microsoft Outlook”

1. Make sure your clients have followed the procedure for updating the operating system to the new DST settings for “(GMT-04:00) Santiago”

2. Download and run the “Time Zone Data Update Tool for Microsoft Outlook” installation package.

Optionally, the administrator can make the installation package available through a local file share.

3.    After the installation package has been installed, the tool will run in its default mode automatically, presenting the following dialog:

 

Click OK to update the appointments for “(GMT-04:00) Santiago”.

 

4. The next screen will show the appointments that have been detected by the tool.  It will include single instance and recurrence appointments affected during the delta period.

Click on “Details >>” to get the complete list.

 

 

5.    From this list you can uncheck any appointments you don’t want to correct. After reviewing the appointments, click “OK” to proceed moving the appointments. The following dialog will appear showing the results for the operation: 

 

 

6.  You can inspect the log file where the tool registers the changes made to each individual item with the “Open Log” button.  The log will be saved to the %temp% directory with the name “Outlook Time Zone Update.log".

 

Example of how to run the "Time Zone Data Update Tool for Microsoft Outlook" in QUIET mode

Quiet mode allows the tool to install and execute without the user’s intervention. You can run this mode from a login script to automate the update process for your users. This procedure only updates the default Mapi profile.

Installation package options:

 

NOTE: Do not confuse the installation package with the tool itself (both have the same name tzmove.exe)

1. Run Tzmove.exe /quiet to install the package. This will install the tool but does not run the tool after installation is complete.

2. The installation log file "Time Zone Data Update Tool for MicrosoftOffice Outlook (n).log" will be created under %temp% directory.
If you need to verify the tool has installed successfully, look for the following line at the end of that log:

"Product: Time Zone Data Update Tool for Microsoft Office Outlook -- Installation completed successfully."

3. Run  the tool from the installation directory

For a 32-bit OS, type the following command:
"%PROGRAMFILES%\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\tzmove.exe" /quiet

For a 64-bit OS, type the following command:
"%PROGRAMFILES(x86)%\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool\tzmove.exe" /quiet

The log will be saved to the %temp% directory with the name “Outlook Time Zone Update.log”
The tool will automatically send updates to the meeting requests it has moved.

See Additional Recommendations later in this post

 

Using “Microsoft Exchange Calendar Update Configuration Tool”

This option allows you to modify the appointments for all users at the server side. Running this tool will require additional resources and planning from the Exchange Administrator’s side, as described in the article and depicted in the example below. There is also a risk associated with running the Exchange tool, as described in the "Risk of running the Exchange tool" section of the KB 941018

The following knowledge base article explains in detail how to download and use this tool.

941018 How to address daylight saving time by using the Exchange Calendar Update Tool

The tool relies on extracting the time zone information from the user’s mailboxes. Time zone information could not be collected for every user, because not every user takes actions that leave time zone data to collect, such as scheduling recurring meetings, logging onto Outlook Web Access and setting the time zone, or using CDO based applications.  In these cases, is recommended that you instruct the users to set their home time zone through OWA.  If the tool cannot extract the time zone for particular users, these particular users will not have their appointments fixed by the Exchange too, and should run the “Time Zone Data Update Tool for Microsoft Outlook”, TZMOVE.EXE.

 

Additional Recommendations

The following are general recommendations and precautions that apply to all methods:

·      Simulate the changes on a lab environment, so you know what will happen and what to expect.

·      Work in conjunction with the operating system team to update the DST dates as soon as possible to minimize the chance of users creating new appointments during the delta period before the operating system DST dates get updated. Update the Outlook calendar as soon as the Operating System update is performed. 

·      Before doing any change on the DST information, request the users to print their schedule during the delta period so they have a point of reference. This will help you can keep track of which meetings were scheduled before and after you run the tools. Note that the patch contains the updated time zone definitions

·      Include the time of the meeting in the e-mail request so that invitees can double check the correct meeting time (such as, "Project brainstorming - 11:00 A.M. Central Time"). 

·      For the meetings with multiple attendees only the meeting requestor should update the time and send the update to the others.

 

Cambio de horario de verano en Chile – Cómo actualizar Windows en servidores y estaciones de trabajo

El gobierno de Chile ha anunciado una extensión del horario de verano (DST) para el huso horario “(GMT -04:00) Santiago”

 

Las fechas originales definidas para el período 2007-2008 son:

Comienzo horario de verano: Sábado 13 de Octubre del 2007 23:59:59.
Ultimo día de horario de verano: Sábado 8 de Marzo del 2008 23:59:59.

 

Las nuevas fechas definidas para el período 2007-2008 son:

Comienzo horario de verano: Sábado 13 de Octubre del 2007 23:59:59.
Ultimo día de horario de verano: Sábado 29 de Marzo del 2008 23:59:59.

 

Durante este período el horario estará 1 hora adelantado con relación al horario normal. En términos prácticos, vale decir que el horario de verano se extenderá hasta el 29 de Marzo del 2008.

Desde la perspectiva de los sistemas operativos Windows, este cambio implica la actualización de la información de la zona horaria “(GMT -04:00) Santiago”, correspondiente a Pacific SA Standard Time con la nueva información provista por el gobierno de Chile.

El siguiente artículo describe como hacerlo.

“Daylight Saving Time change in Chile – How to update Windows Server and Desktop operating systems”

 

Consideraciones para usuarios de Microsoft Exchange y Microsoft Outlook

Luego de actualizar la zona horaria en los sistemas operativos Windows, el calendario de los clientes Outlook mostrará sus ítems una hora adelantada con respecto a la original durante el período entre el 9 de Marzo y el 29 de Marzo inclusive. Este período es conocido como “Delta” y comprende la diferencia de fechas entre el horario de verano original y el nuevo. El siguiente artículo explica como modificar los ítems de calendario en Outlook para que reflejen la hora correcta luego del cambio de zona.

“Daylight Saving Time change in Chile – Effects on Outlook clients and Exchange Servers”

 

Cambio de horario de verano en Chile - Efecto en clientes Outlook y servidores Exchange

El gobierno de Chile ha anunciado una extensión del horario de verano (DST) para el huso horario “(GMT -04:00) Santiago”

 

Las fechas originales definidas para el período 2007-2008 son:

Comienzo horario de verano: Sábado 13 de Octubre del 2007 23:59:59.
Ultimo día de horario de verano: Sábado 8 de Marzo del 2008 23:59:59.

 

Las nuevas fechas definidas para el período 2007-2008 son:

Comienzo horario de verano: Sábado 13 de Octubre del 2007 23:59:59.
Ultimo día de horario de verano: Sábado 29 de Marzo del 2008 23:59:59.

 

Durante este período el horario estará adelantado 1 hora con relación al horario normal. En términos prácticos, vale decir que el horario de verano se extenderá hasta el 29 de Marzo del 2008.

Desde la perspectiva de los sistemas operativos Windows, este cambio implica la actualización de la información de la zona horaria “(GMT -04:00) Santiago”, correspondiente a Pacific SA Standard Time con la nueva información provista por el gobierno de Chile.

 

Luego de actualizar la zona horaria en los sistemas operativos Windows basándonos en el artículo “Daylight Saving Time change in Chile – How to update Windows Server and Desktop operating systems”, el calendario de los clientes Outlook mostrará sus ítems una hora adelantada con respecto a la original durante el período entre el 9 de Marzo y el 29 de Marzo inclusive. Este período es conocido como “Delta” y comprende la diferencia de fechas entre el horario de verano original y el nuevo.

El siguiente artículo explica como modificar los ítems de calendario en Outlook para que reflejen la hora correcta luego del cambio de zona:

“Daylight Saving Time change in Chile – Effects on Outlook clients and Exchange Servers”

Daylight Saving Time change in Chile – How to update Windows Server and Desktop operating systems

Background

The government of Chile announced last February 07th 2008 that their current daylight saving time will be extended in order to save energy. The new fall back date for the daylight saving period of 2007-2008 is:

• Daylight saving time ends:  Saturday, March 29th, 2008 11:59:59 PM
  

Currently, computers in Chile use the “(GMT-04:00) Santiago” time zone setting. The default configuration for this time zone setting in Windows Operating Systems does not reflect the new final date for the daylight saving time defined by the government.

How to update Windows Servers and Desktop Operating Systems

At the time of writing this post, there is no hotfix available to update Windows Operating Systems with the new DST dates for Chile.

The procedures described below are based on KB 914387, which at the time of writing this post, does not contain information about the new DST settings for Chile. If you are in doubt about these procedures, consult the article for more details.

Updating Windows Servers and Desktop Operating Systems

This procedure shows how to update the definition for “(GMT-04:00) Santiago” time zone to reflect the DST dates defined by the Chilean government.

Daylight saving time begins: Second Saturday of October at 11:59:59 PM
Daylight saving time ends: Last Saturday of March at 11:59:59 PM

1. Create a registry file that contains the new DST settings for Chile, following the steps below:

a. Click Start, click Run, type notepad, and then click OK.

b. Copy the following registry information, and then paste it into the Notepad document:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Pacific SA Standard Time] "TZI"=hex:f0,00,00,00,00,00,00,00,c4,ff,ff,ff,00,00,03,00,06,00,05,00,17,00,3b,\   00,3b,00,00,00,00,00,0a,00,06,00,02,00,17,00,3b,00,3b,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Pacific SA Standard Time\Dynamic DST] "FirstEntry"=dword:000007d7 "LastEntry"=dword:000007d8 "2008"=hex:f0,00,00,00,00,00,00,00,c4,ff,ff,ff,00,00,03,00,06,00,05,00,17,00,3b,\   00,3b,00,00,00,00,00,0a,00,06,00,02,00,17,00,3b,00,3b,00,00,00 "2007"=hex:f0,00,00,00,00,00,00,00,c4,ff,ff,ff,00,00,03,00,06,00,02,00,17,00,3b,\   00,3b,00,e7,03,00,00,0a,00,06,00,02,00,17,00,3b,00,3b,00,e7,03

c. On the File menu, click Save As.

d. Select a destination, and then type TZupdate.reg in the File name box. 

e. In the Save as type box, click All Files, and then click Save.

2. Import this registry key on target machines by double clicking in the TZupdate.reg and clicking ‘Yes’ when prompted. All machines (clients and servers) must be updated with this registry information.

Note: The user must have administrative privileges to import the registry key. If the user does not have administrative privileges, then distribute the registry key via startup script as described on the session ‘Deploying the DST modifications using Group Policy’ below.

a. After you import the registry keys, you will need to refresh the configuration by either running the command:
control.exe timedate.cpl,,/Z Pacific SA Standard Time
or making a temporary change in the Date and Time properties (for example, uncheck/apply, then check/apply the “Automatically adjust clock for daylight saving changes”).

b. The script provide in step 3 already refreshes the DST configuration. You do not need to manually refresh the DST information if run the script.

3. In order to deploy these time zone changes in a corporate environment, you can use a startup script as described below.

Time zone information is stored in two locations. We need to make sure these locations are updated. Importing the TZupdate.reg file updates the time zone database in the registry. Next, you must create a script that updates the time zone information registry key in the CurrentControlSet branch. You can deploy this script by using Group Policy or another deployment mechanism.

The script identifies the current time zone of the client computer and then reloads the Time Zone Information registry key with the updated information from the time zone database. Then, the script writes an event to the Application log of the client computer where the script was run.

To create the script file, follow these steps.

a. Click Start, click Run, type notepad, and then press ENTER.

b. Copy the following code, and then paste it into the Notepad document.

Set objSh = CreateObject("WScript.Shell") 'Get the StandardName key of the current time zone szStandardName = objSh.RegRead("HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardName") 'Enumerate the subkeys in the time zone database const HKEY_LOCAL_MACHINE = &H80000002 Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv") szTzsKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones" objReg.EnumKey HKEY_LOCAL_MACHINE, szTzsKeyPath, arrTzSubKeys 'Step through the time zones to find the matching Standard Name szTzKey = "<Unknown>" For Each subkey In arrTzSubKeys     If (objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & subkey & "\Std") = szStandardName) Then         'Found matching StandardName, now store this time zone key name         szTzKey = subkey     End If Next If szTzKey = "<Unknown>" Then        'Write entry to the Application event log stating that the update has failed to execute        objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer.  Time zones failed to enumerate properly or matching time zone not found."        Wscript.Quit 0 End If Dim process, processid, result, strUpdateCommand Set process = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2:Win32_process") 'Add time change privilege to the process object process.Security_.Privileges.AddAsString "SeSystemTimePrivilege",True strUpdateCommand = "control.exe timedate.cpl,,/Z" & szTzKey 'Launch control.exe to refresh time zone information using the TZ key name obtained above result = process.create(strUpdateCommand,Null,Null,processid) If result <> 0 Then        objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer.  Unable to refresh the Timezone database."     Wscript.Quit 0 End If 'Get current display name of refreshed time zone szCurrDispName = objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & szTzKey & "\Display") 'Write entry to the Application event log stating that the update has executed objSh.LogEvent 4, "DST 2007 Registry Update and Refresh has been executed on this computer." & chr(13) & chr(10) & chr(13) & chr(10) & "Current time zone is: " & szCurrDispName & "."

c. On the File menu, click Save As.

d. Select a destination, and then type “refreshTZinfo