Hola a todos,
En alguna ocasiones necesitamos actualizar un equipo y esta tarea se nos complica al tener que buscar los parches que existen publicados para una tecnología concreta.
Tenemos Windows Update, pero puede ser complicado diferenciar que parches aplican a una tecnología u otra y no permite ver los fixes publicados, ante esta situación localicé, para uno de nuestros casos, una web de Technet que contiene las ultimas actualizaciones que hemos publicado respecto a Hyper-V.
En ella viene detallado el artículo, si esta en Windows Update o solo como Fix, y para que entorno aplica cada uno, todo esto en un cuadro, lo que simplifica mucho esta tarea.
Lo tenéis en: http://technet.microsoft.com/en-us/library/dd430893(WS.10).aspx
Espero que os resulte de utilidad.
Consulta con el equipo de Windows.
En Microsoft System Center Virtual Machine Manager 2008 R2, cuando eliminas un disco duro virtual (VHD) de una máquina virtual espera que el fichero .vhd únicamente se desasigne de la maquina virtual. Si embargo el fichero vhd es eliminado del servidor de Hyper-V.
Hemos publicado un Fix que soluciona este comportamiento. Puedes leer los detalles y acceder al Fix para instalarlo en:
KB976246 - When you remove a virtual hard disk from a virtual machine in System Center Virtual Machine Manager 2008 R2, the .vhd file on the Hyper-V server is deleted without warning
Tras aplicar este fix aparece el siguiente mensaje al realizar esta acción:
You have chosen to remove virtual hard disks from virtual machine VMName. This action will delete the .vhd files. Do you want to continue?
Si pulsas Yes, el fichero .vhd es borrado del Hyper-V server. Si pulsas en No, el fichero .vhd se mantiene unido a la maquina virtual y no es eliminado del Hyper-V server.
Un saludo.
Como todos sabéis, los Controladores de Dominio de un dominio sincronizan su servicio de tiempos siguiendo la jerarquía del dominio. Generalmente, el PDC Emulator del dominio raíz del bosque se configura para que sincronice su hora con una fuente externa o con su propio reloj hardware, tal y como se indica en el artículo:
816042 How to configure an authoritative time server in Windows Server
Si el rol de PDC Emulator en el dominio raíz del forest se mueve a otro DC, además de configurar el nuevo PDC, también debe indicarse al PDC antiguo que ya no es una fuente de hora autoritativa en el entorno, ya que la operación de transferencia del rol no realiza esta operación sobre el servicio de tiempos.
Si no se realiza la operación, el antiguo PDC sigue anunciándose y actuando como fuente de tiempos autoritativa, lo que hace que el resto de DCs, si no tienen fallos al contactar con él o no realizan de nuevo el proceso selección de una nueva fuente de tiempos, sigan sincronizándose contra esta máquina.
El procedimiento que hay que llevar a cabo en el PDC antiguo se describe en el artículo Change the Windows Time service configuration on the previous PDC emulator y consiste en ejecutar los comandos que aparecen a continuación:
w32tm /config /syncfromflags:domhier /reliable:no /update
net stop w32time && net start w32time
Tras realizar esta modificación, el antiguo PDC deja de anunciarse como fuente de tiempos y, por lo tanto, el resto de los DCs procederán a buscar una nueva fuente de tiempos una vez agotados los tiempos de polling.
Espero que encontréis útil esta información.
Paula Tomás Galed
Hola a todos.
Frecuentemente recibimos preguntas en soporte relacionadas con la distribución de la configuración 802.1x para los puestos cliente de una infraestructura de red.
Como veremos a continuación, la respuesta a esto depende del sistema operativo sobre el que queramos realizar la configuración:
Windows XP SP3 (válido para Windows Vista, Windows 7 y Windows Server 2008 y R2)
En el caso del Windows XP, necesitaremos crearnos un perfil en un fichero .xml a través de la herramienta netsh.
La idea sería:
1. Realizar la configuración deseada en un puesto cliente. 2. Exportar la configuración a un fichero .xml a través de la siguiente sentencia desde la línea de comandos: netsh lan export profile folder=c:\Ruta 3. En la ruta seleccionada, encontraremos un fichero .xml 4. Para cargar la configuración en otro equipo diferente, ejecutaríamos lo siguiente: netsh lan add profile filename=FicheroPerfil.xml A partir de aquí, podríamos crear un script (o utilizar aplicaciones de distribución de software como System Center Configuration Manager) para ejecutar esta última sentencia en todos los puestos Windwos XP SP3 en los que nos interese configurar 802.1x.
1. Realizar la configuración deseada en un puesto cliente.
2. Exportar la configuración a un fichero .xml a través de la siguiente sentencia desde la línea de comandos:
netsh lan export profile folder=c:\Ruta
3. En la ruta seleccionada, encontraremos un fichero .xml
4. Para cargar la configuración en otro equipo diferente, ejecutaríamos lo siguiente:
netsh lan add profile filename=FicheroPerfil.xml
A partir de aquí, podríamos crear un script (o utilizar aplicaciones de distribución de software como System Center Configuration Manager) para ejecutar esta última sentencia en todos los puestos Windwos XP SP3 en los que nos interese configurar 802.1x.
Por políticas de dominio (válido para Windows Vista, Windows 7 y Windows Server 2008 y R2)
A diferencia del punto anterior, para estos sistemas operativos disponemos de políticas de dominio para realizar la configuración deseada en: Computer Configuration/Windows Settings/Security Settings/Wired Network (IEEE 802.3) Policies Podéis encontrar más información relacionada con este tema en los siguientes artículos: Netsh Commands for Wired Local Area Network (LAN) in Windows Server 2008 and Windows Server 2008 R2 929847 - How to enable computer-only authentication for a 802.1X-based network in Windows Vista, in Windows Server 2008, and in Windows XP Service Pack
A diferencia del punto anterior, para estos sistemas operativos disponemos de políticas de dominio para realizar la configuración deseada en:
Computer Configuration/Windows Settings/Security Settings/Wired Network (IEEE 802.3) Policies
Podéis encontrar más información relacionada con este tema en los siguientes artículos:
Esperamos que esta información os haya sido de utilidad.
Un saludo,
Javier Rama.
Recientemente nos hemos encontrado con un caso curioso, en el que hemos estado trabajando unas cuantas semanas, que implica tanto a la parte de Core como de Directorio Activo y queríamos comentároslo. Esperamos que os sea de utilidad :).
Cuando un usuario se conecta a un servidor de Terminal Server, el servidor de licencias registra el siguiente evento:
Event ID 4105 Source Microsoft-Windows-TerminalServices-Licensing Type Warning Description The Terminal Services license server cannot update the license attributes for user "user" in the Active Directory Domain "domain". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "domain". If the license server is installed on a domain controller the Network Service account also needs to be a member of the Terminal Server License Servers group. If the license server is installed on a domain controller after you have added the appropriate accounts to the Terminal Server License Servers group you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs. Win32 error code: 0x80070005
Event ID 4105
Source Microsoft-Windows-TerminalServices-Licensing
Type Warning
Description
The Terminal Services license server cannot update the license attributes for user "user" in the Active Directory Domain "domain". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "domain".
If the license server is installed on a domain controller the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller after you have added the appropriate accounts to the Terminal Server License Servers group you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs.
Win32 error code: 0x80070005
El error 4105 ocurre en los usuarios migrados desde un entorno NT/2000. Cuando se actualiza el esquema del dominio a 2003, los usuarios creados a partir de ese momento, incluyen permisos de lectura/escritura para el grupo Terminal Server License Servers en su security descriptor. Esto es debido a que el grupo Terminal Server License Servers se crea al ampliar el esquema a 2003 ya que en 2000 no existía y se modifica el defaultSecurityDescriptor de la clase user añadiendo la siguiente ACE:
(OA;;WPRP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)
Donde:
Llegados a este punto tenemos dos posibilidades:
Para ello, lo que tenemos que hacer es ejecutar el comando dsacls "dc=XXXX,dc=XXXX,dc=XXXX,dc=XXXX” /I:T /G "BUILTIN\Terminal Server License Servers”:WPRP;terminalServer”. Por ejemplo, si nuestro dominio se llamase contoso.com el comando sería:
dsacls "dc=contoso,dc=com” /I:T /G "BUILTIN\Terminal Server License Servers”:WPRP;terminalServer”
dsacls "CN=XXXX,OU=XXXX,OU=XXXX,OU=XXXX,DC=XXXX,DC=XXXX,DC=XXX" /G "BUILTIN\Terminal Server License Servers:WPRP;terminalServer"
Este comando lo que hace es precisamente dar permisos de lectura/escritura al grupo Terminal Server License Servers sobre la propiedad terminalServer de un usuario. Por tanto, lo que necesitamos para resolver el problema es identificar todos los usuarios creados antes de actualizar el esquema a 2003 (y que vayan a acceder a través de terminal server) y darle los permisos antes mencionados.
En este punto es necesario identificar los usuarios sobre los que necesitamos dar los permisos, basándonos en la pertenencia a un grupo o en la fecha de creación. Si os vais a basar en la pertenencia a grupos, os recomendamos seguir los pasos descritos en el siguiente post: Diversas herramientas no muestran todos los miembros de un grupo en el Directorio Activo De acuerdo con el post, un posible script sería como el siguiente: Set objGroup = GetObject _ ("LDAP://cn=XXXX, ou=XXXX, dc=XXXX, dc=XXXX”) set objShell = WScript.CreateObject("WScript.Shell") For Each strUser on objGroup.Member Wscript.Echo strUser set objExec = objShell.Exec("dsacls """ + strUser + """ /G ""BUILTIN\Terminal Server License Servers:WPRP;terminalServer""") El anterior script daría permisos a 1000 usuarios pertenecientes a un grupo administrativo. Si el número de usuarios es mayor, habría que utilizar otro script. Nuestros compañeros de desarrollo nos han comentado que el script se complicaría bastante por lo que os recomendamos abrir un caso con ellos para que os puedan guiar de la mejor manera. Asimismo, si lo que queremos es dar permisos a usuarios de una OU específica el script también sería diferente. Por último, si os queréis basar en la fecha de creación de los usuarios también deberíamos utilizar un script diferente y bastante más complejo. Además, necesitaríamos utilizar un filtro para la query LDAP del tipo (&(objectclass=user)(whenCreated>=20010420235531.0Z)(whencreated<=20010420235531.0Z).
En este punto es necesario identificar los usuarios sobre los que necesitamos dar los permisos, basándonos en la pertenencia a un grupo o en la fecha de creación. Si os vais a basar en la pertenencia a grupos, os recomendamos seguir los pasos descritos en el siguiente post:
Diversas herramientas no muestran todos los miembros de un grupo en el Directorio Activo
De acuerdo con el post, un posible script sería como el siguiente:
Set objGroup = GetObject _
("LDAP://cn=XXXX, ou=XXXX, dc=XXXX, dc=XXXX”)
set objShell = WScript.CreateObject("WScript.Shell")
For Each strUser on objGroup.Member
Wscript.Echo strUser
set objExec = objShell.Exec("dsacls """ + strUser + """ /G ""BUILTIN\Terminal Server License Servers:WPRP;terminalServer""")
El anterior script daría permisos a 1000 usuarios pertenecientes a un grupo administrativo. Si el número de usuarios es mayor, habría que utilizar otro script.
Nuestros compañeros de desarrollo nos han comentado que el script se complicaría bastante por lo que os recomendamos abrir un caso con ellos para que os puedan guiar de la mejor manera. Asimismo, si lo que queremos es dar permisos a usuarios de una OU específica el script también sería diferente.
Por último, si os queréis basar en la fecha de creación de los usuarios también deberíamos utilizar un script diferente y bastante más complejo. Además, necesitaríamos utilizar un filtro para la query LDAP del tipo (&(objectclass=user)(whenCreated>=20010420235531.0Z)(whencreated<=20010420235531.0Z).
Rafael Basterra Careaga y Yolanda Muñoz Muñoz
Recientemente se nos planteó un caso de este tipo en soporte. En este caso era debido a que los DCs Windows Server 2003 se estaban “comportando” como Windows NT. Aquí tenéis toda la histora:
Entorno:
Problema:
An Active Directory Domain Controller (AD DC) for the domain DOMINIO.COM could not be contacted. Ensure that the domain name is typed correctly
The following error occurred attempting to join the domain DOMINIO: The specified domain either does not exist or could not be contacted
A su vez, determinamos que los mismos servidores Win2008R2 SÍ podían unirse correctamente utilizando el nombre FQDN a otros dominios del mismo entorno
Observamos que, en principio, los DCs respondían “correctamente” a las peticiones de los clientes (no había cortes de tráfico ni errores en las comunicaciones entre los prospectivos servidores miembros 2008R2 y los DCs). A pesar de ver que recibían “respuestas” por parte de los DCs, los equipos Win2008R2 persistían en repetir las mismas peticiones para localizar información del dominio al que se querían unir, hasta finalmente fallar con los errores ya citados
Investigación
El problema finalmente tenía 2 matices:
1)
298713 How to prevent overloading on the first domain controller during domain upgrade
The NT4Emulator parameter specifies whether this domain controller will emulate the behavior of an Windows NT 4.0-based domain controller. By default, the domain controller does not emulate this behavior. Emulation of the Windows NT 4.0 behavior is desirable when the first domain controller that is running Windows 2000 or a later version of Windows is promoted to a primary domain controller in a Windows NT 4.0 domain that has many Windows 2000-based clients. Unless you emulate the Windows NT 4.0 behavior, all the Windows 2000-based clients will target the Windows-based domain controller and potentially overload it. This parameter is ignored on computers that are not domain controllers.
If this parameter is set to TRUE, the following scenario occurs on a domain controller:
2)
940268 Error message when you try to join a Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2-based computer to a Windows NT 4.0 domain: "Logon failure: unknown user name or bad password"
Resolución
Tolu Igbon
En el siguiente video, podréis ver una demostración del funcionamiento del cumplimiento de NAP para DHCP en un entorno basado en tres máquinas:
· Un Controlador de dominio
· Un servidor NPS y DHCP
· Un equipo cliente.
Información adicional relacionada con este Screencast en los siguientes documentos:
Demostrate NAP DHCP Enforcement in a Test Lab
http://www.microsoft.com/Downloads/details.aspx?FamilyID=ac38e5bb-18ce-40cb-8e59-188f7a198897&displaylang=en
Technet Magazine: Control Network Access Using DHCP Enforcement
http://technet.microsoft.com/en-us/magazine/2009.05.goat.aspx?pr=blog
Hace ya algún tiempo que Power Shell nos abrió paso a un modo más sencillo y potente de hacer las cosas. En esta ocasión me acerco a vosotros para mostraros otro modo de administrar clúster fuera de la consola y los comandos propios proporcionados por clúster.
La lista completa podéis encontrarla en la siguiente URL:
Failover Cluster Cmdlets in Windows PowerShell
A continuación os muestro algunos ejemplos:
Listado de la propiedades del Clúster
C:\> Get-Cluster | FL * Donde FL es el alias de Format-List
C:\> Get-Cluster | FL *
Donde FL es el alias de Format-List
Crear un servidor de ficheros
C:\> Add-ClusterFileServerRole –Storage “Cluster Disk 3” –Name Win2008R2FS1 – StaticAddress 192.168.1.100
Exportar a texto el log de Clúster
C:\> Get-ClusterLog –Cluster Win2008R2Cluster –Node nodo1 –Destination C:\Logs
Paloma García Martín
Debido a la eliminación de contenidos en el soporte que teniamos para los videos estan todos con error en el link.
Estamos preparando una nueva ubicación y esperamos tenerlos todos de nuevo activos en breve.
Un saludo y disculpad la espera.
Hola de nuevo. Volvemos a la “carga” con LDAP. Hoy vamos a hablar sobre cómo obtener un logging detallado de las consultas LDAP llevadas a cabo por un controlador de dominio. Esto puede resultarnos útil a la hora de comprobar el tipo de consultas LDAP que se efectúan, comprobar si están optimizadas en cuanto a objetos recorridos, etc.
Para qué nos sirve
Los datos obtenidos pueden ayudarnos a determinar, por ejemplo, si hay un cliente que está efectuando muchas consultas y que, en principio, no debería estar realizando, lo que puede indicar la presencia de alguna aplicación no deseada.
También puede ayudarnos a determinar si es necesario indexar algún atributo concreto para optimizar un tipo de búsqueda concreta que se realiza de forma frecuente y con un filtro que utiliza un atributo específico no indexado (lo que provoca recorrer innecesariamente múltiples objetos por cada búsqueda).
Es posible que estemos realizando la búsqueda en un scope o ámbito muy amplio y con un DN base muy general cuando podemos restringirla a una OU concreta y no a todo el sub-árbol del dominio: si buscamos usuarios de una oficina concreta que cumplen un requisito y sabemos que todos los usuarios de dicha oficina están en una OU específica, deberíamos utilizar dicha OU como DN base de la búsqueda y no todo el dominio.
Este logging de las consultas LDAP se realiza en el visor de sucesos en forma de eventos. Los eventos generados proporcionan, además de los datos del cliente y la propia consulta, información adicional como el tiempo empleado en las queries LDAP y los objetos recorridos.
Para leer información sobre cómo funcionan las búsquedas LDAP: How Active Directory Searches Work
Cómo configurar este nivel de logging
Para conseguir este nivel de logging, en los DCs hay que hacer varias modificaciones en el registro para:
En primer lugar hay que definir los límites a partir de los cuales se considera que una consulta es costosa/ineficiente. Estos límites se especifican en términos de objetos recorridos, y sólo se registrarán eventos que superen estos límites.
Una búsqueda costosa es aquella que visita un alto número de objetos. La eficiencia de una búsqueda se mide comparando el número de registros devueltos con respecto al número de registros visitados. Es decir, si la búsqueda devuelve 300 objetos después de recorrer 300 objetos, entonces estamos ante una búsqueda eficiente.
Los límites se especifican con creando o modificando los siguientes valores de la clave de registro que se proporciona a continuación (si se desea que se muestren todas las consultas LDAP, el valor de ambos límites deberá ser 1, aunque esto puede suponer un incremento no deseado de la carga de CPU del DC):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Tipo: DWORD Datos: 10000 (Valor por defecto)
Tipo: DWORD
Datos: 10000 (Valor por defecto)
Tipo: DWORD Datos: 1000 (Valor por defecto)
Datos: 1000 (Valor por defecto)
Con estos valores por defecto, una búsqueda se considerará costosa si el DC recorre más de 10000 objetos (Expensive Search Results Threshold). Una búsqueda se considerará ineficiente si recorre más de 1000 objetos (Inefficient Search Results Threshold) y se devuelve como resultado menos de un 10% de los objetos visitados.
Los valores de Expensive e Inefficient Search Results Threshold son valores subjetivos, por lo que habrá que adecuarlos al entorno y al tipo de consultas que se efectúen en los DCs.
Se puede encontrar más información sobre estos valores en el siguiente enlace:
Creating More Efficient Microsoft Active Directory-Enabled Applications
Hasta aquí ya hemos determinado nuestros valores límite de lo que consideramos una búsqueda costosa o ineficiente. Sin embargo, esto no es suficiente para generar los eventos.
Los eventos de log de actividad LDAP se generan en el visor de sucesos de Directorio Activo en la categoría de Field Engineering. Por lo tanto, tendremos que activar el log de diagnóstico de esta categoría en los DCs en los que queramos monitorizar la actividad LDAP.
Para ello es necesario modificar el siguiente valor de la clave de registro que se muestra a continuación:
HKLM\system\CCS\Services\NTDS\Diagnostics
Datos: 5
Nota: Para que los valores sean efectivos no es necesario reiniciar el DC en el que se modifiquen
A partir de dicho momento, por cada query LDAP costosa/ineficiente aparecerá en el Visor de Sucesos de Directory Services un evento 1644 de categoría Field Engineering con la información de la búsqueda, tipo, filtro, ámbito de búsqueda (scope), entradas recorridas, entradas encontradas, etc.:
Event Type: Information
Event Source: NTDS General
Event Category: Field Engineering
Event ID: 1644
Internal event: A client issued a search operation with the following options.
Client:
127.0.0.1
Starting node:
DC=dominio,DC=com
Filter:
(objectClass=computer)
Search scope:
subtree
Attribute selection:
[types_only]
Server controls:
Visited entries:
3448
Returned entries:
7
Otro tipo de log de diagnóstico que puede resultar útil es el siguiente, que nos permite obtener información sobre el tiempo empleado en las búsquedas:
Datos: 3
Después de habilitarlo obtendremos un evento 1139 de LDAP Interface indicando el tiempo que ha costado realizar cada búsqueda:
Event Type: Information Event Source: NTDS LDAP Event Category: LDAP Interface Event ID: 1139 Description: Internal event: Function ldap_search completed with an elapsed time of 30 ms.
Event Source: NTDS LDAP
Event Category: LDAP Interface
Event ID: 1139
Internal event: Function ldap_search completed with an elapsed time of 30 ms.
Para revisar los eventos generados por los DCs y obtener, por ejemplo, todos los eventos con ID 1644 y fuente NTDS General de todos los DCs que estemos monitorizando, podemos usar una herramienta como EventCombMT. La herramienta EventCombMT se puede descargar desde el siguiente enlace:
También es recomendable que aumentemos el tamaño del log de Directory Services, ya que se van a generar varios eventos por cada consulta LDAP registrada, lo que podría provocar que dicho visor de sucesos llegara a su tamaño máximo.
Hasta la próxima.
Hola a todos. Soy Paula, del equipo de Directorio Activo. Hoy vamos a tratar un tema por el que nos preguntan en Soporte.
A veces, cuando se realizan consultas LDAP a Directorio Activo (utilizando alguna herramienta o programa a medida), no se devuelven todos los resultados que esperamos. Podemos, por ejemplo, solicitar todos los usuarios de una determinada Unidad Organizativa en la que sabemos que hay 3000 usuarios para luego realizar algunas modificaciones sobre ellos. Sin embargo, al ejecutar la consulta LDAP, AD sólo nos devuelve 1000 usuarios, con lo cual la búsqueda no nos sirve...
Este comportamiento se debe a que Directorio Activo devuelve por defecto un máximo número de objetos (1000) en una única búsqueda, aunque los objetos que cumplan los parámetros de búsqueda sean más de ese número por defecto. Este límite viene dado por el valor MaxPageSize de la política LDAP en Directorio Activo.
El valor puede ser modificado y adaptado a las necesidades concretas que tengamos. Para modificar dicho valor es necesario realizar la operación con un usuario con credenciales de Enterprise Admin.
No se recomienda cambiar su valor para recibir un mayor número de objetos en una única consulta LDAP, sino realizar búsquedas paginadas en el Directorio Activo. De esta manera se dividirá la búsqueda en varias búsquedas “más pequeñas” que cumplirán con el límite máximo establecido para cada una de ellas.
¿Por qué no se recomienda cambiar el valor de MaxPageSize?
Porque su modificación puede producir efectos negativos sobre el rendimiento de los DCs y el tráfico generado en la red.
Se puede encontrar más información sobre el valor MaxPageSize y cómo consultarlo y/o modificarlo con ntdsutil.exe en el siguiente enlace:
315071 How to view and set LDAP policy in Active Directory by using Ntdsutil.exe
“MaxPageSize - This value controls the maximum number of objects that are returned in a single search result, independent of how large each returned object is. To perform a search where the result might exceed this number of objects, the client must specify the paged search control. This is to group the returned results in groups that are no larger than the MaxPageSize value. To summarize, MaxPageSize controls the number of objects that are returned in a single search result. Default value: 1,000”
Si se modifican los límites establecidos por defecto existe un problema potencial de rendimiento. Estos límites han sido probados y se seleccionaron por considerarse óptimos o recomendables. Para entornos específicos pueden ser modificados pero siempre teniendo en cuenta que pueden suponer un problema de rendimiento en el futuro. También hay que recordar que el valor se cambia a nivel general en la política LDAP de AD, por lo que afectará a todos los DCs.
¿Cómo resolver la situación sin modificar el valor de MaxPageSize?
La recomendación para realizar consultas LDAP es realizar dichas consultas de manera paginada (los diferentes lenguajes de programación a través de APIs para LDAP ofrecen mecanismos para llevar este tipo de búsquedas a cabo), con lo que se recibirían los datos de 1000 en 1000 (registros), en lugar de modificar el tamaño de la página que nos devuelve Directorio Activo. De hecho, aunque aumentemos el tamaño del valor MaxPageSize, es posible que tampoco sea suficiente y la búsqueda no devuelva todos los resultados esperados (el número de objetos puede crecer en el tiempo y superar el nuevo límite de MaxPageSize).
Se puede encontrar más información sobre las diferentes políticas LDAP, incluyendo MaxPageSize en el siguiente enlace:
3.1.1.3.4.6 LDAP Policies
Como ya se ha comentado, las políticas LDAP proporcionan límites operacionales para consultas/operaciones LDAP y deben ser configuradas de tal manera que garanticen un nivel de servicio aceptable sin impactar al rendimiento de los DCs y evitando así también ataques de denegación de servicio.
Información específica sobre las políticas LDAP en Windows Server 2008:
LDAP policies
“To ensure that domain controllers can support service level guarantees, you can specify operational limits for a number of Lightweight Directory Access Protocol (LDAP) operations. These limits prevent specific operations from adversely impacting the performance of the server and also make the server resilient to denial of service attacks.”
Más información sobre los límites administrativos de LDAP para AD en la información sobre la herramienta Microsoft Exchange Server Analyzer Tool que analiza configuraciones erróneas entre otros:
Microsoft Exchange Server Analyzer Tool – Active Directory settings MaxPageSize is set too high
“The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the setting for the MaxPageSize value for the LDAPAdminLimits attribute of the Default Query Policy object in the Query-Policies container. If the Exchange Server Analyzer determines that the value for MaxPageSize is greater than 2,500, an error is displayed.
The Lightweight Directory Access Protocol (LDAP) administrative limits balance Active Directory operational capabilities and performance. These limits prevent specific operations from adversely affecting the performance of the server. The limits also make the server resilient to denial of service attacks. Increasing this setting beyond its default value could have an adverse impact on your Active Directory infrastructure.“
Información adicional sobre las búsquedas paginadas:
Espero que la información os resulte útil a la hora de realizar consultas LDAP en vuestro directorio.
Hola nuevamente!
Todos sabemos que para diagnosticar problemas de performance en un servidor debemos configurar contadores de performance de los objetos que deseamos analizar.
Ahora bien, ¿Quién sabe leer toda la información que se genera con el performance monitor?
Solemos tener mucha cantidad de información, muchos contadores, mucha interacción entre ellos y muchas veces se hace imposible lograr una idea de lo que está sucediendo.
Para solucionar este problema contamos con la herramienta llamada PAL.
Esta herramienta de uso libre y gratuito genera reportes gráficos y muy detallados del rendimiento de un servidor.
También analiza rendimiento de Microsoft Exchange, SQL Server y Biztalk Server, entre otros.
Una vez que utilicéis dicha herramienta llegará un momento donde os toparéis con un problema. Sólo funciona cuando los contadores están en inglés.
Para ello se desarrolló una herramienta que realiza la traducción de los logs del Español al Inglés y así ser capaces de poder utilizar el PAL sobre dicho log.
Esta herramienta de traducción puede ser descargada desde aquí.
¿Cómo utilizarla?
Espero que les sea de utilidad.
Hasta la próxima
Gastón Gardonio
Hola nuevamente.
Dado la muy repercusión que tuvo el video anterior que realizamos decidimos continuar con este formato cuando sea posible.
Esta vez la presentación está dedicada a la instalación del cliente de SCCM.
Esperamos sus comentarios y si surgen dudas, estamos aquí para responderlas.
El video esta publicado en:
Saludos
Hola de nuevo,
Si la virtualización es beneficiosa de por si, si la combinamos con otras tecnologías las soluciones que se logran son incluso mejores.
La semana pasada, el grupo de Vissual Studio Team System anuncio la publicación de la beta de este nuevo producto para la gestión de labs de pruebas. Visual Studio Team System 2010 Lab Management es una solución integrada que facilita todos los beneficios de la virtualización para la gestión del ciclo de vida de las aplicaciones.
Las características principales son:
La imagen a continuación muestra la arquitectura del Lab Management.
Desde el punta de vista servidor, el servicio Lab Management es uno de los múltiples servicios ejecutándose dentro de Team Foundation Server (TFS). Esto es lo que hace la solución Lab Management unica para software testers y desarrolladores. Ahora puedes mapear tus recursos de laboratorio, como host, maquinas virtuales y almacenamiento a Team Project Collections y Team Projects; Esto alinea las necesidades de almacenamiento con las necesidades del negocio para los proyectos que se están ejecutando.
El servicio de administración de Labs en TFS emplea System Center Virtual Machine Manager (SCVMM) para la administración del entorno de laboratorio y, la creación y gestión de maquinas virtuales, a través de diferentes plataformas de virtualización.
Microsoft Test and Lab Manager es un cliente mejorado basado en Windows Presentation Fundación. El Lab Center en Test y Lab Manager te permite realizar
Algunos links con información interesante:
- Visual Studio Download Page – Dese aquí puedes descargar los componentes necesarios.
- Este video puede guiarte a través del proceso de planificación e instalación de TFS.
- Lab Management Setup Guide download (setup/config del Lab Management)
- Online documentation for Team Test (Documentos sobre las características generales del testeo de aplicaciones y consolas de administración).
- Lab Management blog
Ahora, solo queda virtualizar los entornos de pruebas, y cuando este la versión definitiva, disfrutar de todas sus ventajas.
Raúl del Moral.
Ingeniero de soporte Microsoft Premier.
Hola a tod@s,
A nivel mundial se esta levantando una gran expectación alrededor de esta herramienta que permite, el paso de maquinas virtuales entre nodos de un clúster, de forma transparente para el usuario final, y sin afectar al servicio.
Se publico una serie de de videos con los paso a paso para la versión Beta del producto por parte de mi compañero Giovanni Marchetti, la cual podeis revisar desde:
Con la llegada de la RC de la herramienta Hyper-V Live Migration ha actualizado el primer video publicada en Technet en la cual explica paso a paso el manejo de la herramienta. Teniendo previsto ir actualizando el resto de los videos en breve.
Podéis acceder a la actualización del primer video desde update , en el se explican las mejoras incluidas en este versión RC para R2.
Lo podéis revisar junto con al documentación sobre el producto publicada en Technet aqui.
Saludos.
Raúl del Moral
Técnico de Soporte Premier
Este blog es una traducción del post de Mike Kolitz Native support to VHD in W7, en el que se describe la entrada en Windows 7 y Windows Server 2008 R2 de opciones para la creación y la gestión de disco duro virtual (VHD) , además de permitir arrancar una máquina física a partir de un archivo VHD. Esto ayudara a nuestros clientes empresariales y la comunidad de desarrolladores a utilizar un formato de imagen y herramientas comunes para la gestión y despliegue de imágenes de Windows que se ejecutan tanto en Hyper-V con máquinas virtuales como en máquinas físicas.
El disco duro virtual de Microsoft de (VHD) es una especificación de formato de archivo a disposición del público el que se define un disco duro virtual encapsulado en un archivo único, capaz de acoger los sistemas de archivos nativos y apoyo a las operaciones de disco estándar. Los VHD se pueden emplear en Microsoft Windows Server 2008 Hyper-V, Microsoft Virtual Server y Microsoft Virtual PC para los discos virtuales conectados a una máquina virtual. Los VHDs son útiles como contenedores, además el formato de archivo VHD también es utilizado por Microsoft Data Protection Manager, Windows Server Backup así como muchos otros productos y soluciones de Microsoft. Para crear un VHD en Windows Server 2008, anteriormente se tenia que instalar el servidor Hyper-V y usar las APIs de función Hyper-V Manager para crear un archivo VHD para, a continuación, instalar una versión de Windows en una partición en el VHD.
En muchos de nuestros clientes el centro de datos esta en transición a máquinas virtuales Hyper-V para la consolidación de servidores y tener costes energéticos más bajos. También se produce el desplazamiento de un número cada vez mayor de aplicaciones a las máquinas virtuales, que seguirán funcionando en una parte significativa del centro de datos sobre máquinas físicas. La gestión de la integridad de las imágenes que se despliegan a las máquinas físicas y las máquinas virtuales pueden ser un reto. Los administradores de TI tienen que mantener dos conjuntos de imágenes: un conjunto basado en el formato WIM física para máquinas, otro juego basado en el formato VHD de máquinas virtuales. Lo que los administradores necesitan es un formato común y un conjunto de herramientas para hacer más sencilla la administración de imágenes, y reducir así el número de imágenes que se necesita catalogar y mantener.
Desarrolladores y probadores están utilizando máquinas virtuales para probar nuevos sistemas y software de aplicación. Las máquinas virtuales proporcionan una conveniente, y aislada del medio ambiente, forma de reducir la necesidad de prueba en hardware dedicado. Pero a veces es necesario ejecutar las pruebas sobre una máquina física para probar la respuesta al acceder a un dispositivo de hardware , como la tarjeta gráfica, o para obtener perfiles precisos de rendimiento. Un formato de imagen común que se ejecuta tanto en máquinas virtuales como físicas también beneficia a los desarrolladores y probadores.
En esta entrada del blog que vamos a examinar los objetivos del soporte a VHDs como formato nativo en el sistema, el núcleo del sistema operativo compatible con VHDs, y los principales escenarios objeto de despliegue de discos VHD.
Objetivos de soporte nativo para VHDs en Windows Server 2008 R2 y Windows 7
Creación y gestión de VHDs
Windows 7 simplifica la gestión de las imágenes mediante la adición de soporte para discos virtuales en las herramientas de gestión de disco. Ya no es necesario instalar el servidor Hyper-V y el uso de la función Hyper-V Manager para crear VHDs desde la consola. La consola de Administración de Discos puede crear un nuevo archivo VHD, ya sea de tamaño fijo o expandible dinámicamente. Después de crear el archivo VHD, la acción VHD add hace que el disco virtual quede disponible en el sistema como si estuviera enchufado en una unidad de disco duro físico.
Figura 1. Creación de un VHD utilizando la consola Administración de discos
Después de añadir un nuevo disco virtual, se crea una partición y formatea un volumen NTFS en el VHD como si fuera un disco físico. El VHD está listo para que una imagen de Windows se aplique al volumen y se inicialice para arrancar.
Los administradores con frecuencia prefieren herramientas de línea de comandos, y puede hacerse lo mismo desde el cmd, utilizando en diskpart el comando vdisk. Diskpart también acepta una secuencia de comandos para automatizar los pasos para crear y dar formato a un VHD. Cuando un VHD contiene un volumen del sistema de archivos adjunto, Windows reconoce automáticamente el volumen y proporciona una opción para explorar el contenido.
Figura 2. Uso de Diskpart para crear un VHD
Núcleo de Apoyo al Sistema de Almacenamiento El acceso a los contenidos del VHD es proporcionado por un nuevo mini-port driver en la pila de almacenamiento para archivos VHD. El driver es lo que permite las peticiones de E / S de archivos en el VHD ser enviados al sistema de archivos NTFS en la partición donde se encuentra el archivo VHD. Las operaciones también se puede realizar en un recurso VHD compartido en un sistema remoto.
Con Windows Server 2008 R2, Hyper-V ahora utiliza el nuevo soporte nativo para VHDs en el core del sistema operativo. Se han realizado extensas pruebas en una amplia gama de E / S y las pruebaa en escenario con soporte nativa a VHD es increíblemente eficaz. El rendimiento de lectura y escritura, de E / S en diferentes tamaños de bloque, tanto aleatoria como secuencial de E / S, es comparable con el rendimiento del disco físico. Los gráficos siguientes muestran algunos de los resultados preliminares de pruebas de rendimiento en comparación de rendimiento fijo y dinámico sobre archivos VHD entre Windows Server 2008 R2 beta y Windows Server 2008 con Hyper-V. El valor "Bare Metal" muestra el máximo rendimiento de E / S de disco físico al dispositivo sin utilizar un archivo VHD. Baja el rendimiento al escribir sobre un volumen dinámico VHDs debiendose a los múltiples E / S necesarios para ampliar el archivo según nuevos bloques se escriben en el disco virtual.
El soporte desde el Sistema operativo de forma nativa sobre VHD ofrece oportunidades para la gestión de los ISVs al aportar un valor añadido a sus clientes sin la complejidad de la introducción de nuevos formatos de imagen. Hay nuevas API de Win32 para operaciones de la imagen sobre VHD que permiten a las herramientas de gestión apoyar el formato VHD como marco de gestión.
Soporte nativo de arranque VHD El arranque nativo desde VHD permite la transición sin tropiezos a la virtualización mediante un único formato de imagen que arranca tanto en máquinas físicas como máquinas virtuales. El arranque nativo de VHD desde Windows significa que la imagen en un archivo VHD puede arrancar en una máquina física sin iniciar una máquina Hyper-V virtual. Los archivos de imagen VHD hacen que sea fácil que una única máquina física que tenga varias instancias del sistema operativo las tenga disponibles para arrancar en cualquier momento. El soporte al arranque múltiple ha estado disponible en Windows para muchas versiones, pero requería una partición de disco para cada sistema operativo instalado. Ahora soporta de forma nativa el arranque desde VHD de los tres tipos de archivos VHD: fija, dinámica, y diferenciado los discos.
Desarrolladores y probadores pueden utilizar el arranque nativo desde VHD para ejecutar versiones de prueba de nuevos los controladores de dispositivo u otro software para Windows, con pleno acceso a los dispositivos de hardware conectado al sistema. El disco diferencial VHD proporciona una manera conveniente de inicializar un entorno de prueba, la realización de pruebas y la vuelta a un estado limpio o línea de base después de que la prueba se ha completado. La ejecución de pruebas dará lugar a cambios que se realizan sólo en el disco diferencial. Una vez que la prueba está completa, puede volver a limpiar el estado de la matriz del VHD simplemente eliminando el archivo diferencial y mediante la creación de uno nuevo.
El arranque nativo VHD permite a los administradores de TI rápidamente readaptar una máquina para diferentes funciones. Los servidores pueden tener varias aplicaciones de trabajo entre los distintos archivos VHD y cambiar el volumen de trabajo para adaptarse a la demanda. La flexibilidad de múltiples archivos de arranque utilizando VHD también hace que sea fácil de mantener un imagen anterior de Windows disponible para su uso como fall-back en caso de un problema con una nueva imagen.
El arranque nativo desde VHD depende de las mejoras en los datos de configuración de arranque (BCD) para representar el archivo VHD como dispositivo de arranque en lugar de una partición de disco físico. La siguiente imagen muestra un ejemplo de una configuración de arranque múltiple con una entrada de inicio VHD.
Figura 3. Configuración de arranque múltiple con VHD como inicio
El gestor de arranque de Windows 7 y su cargador puede ahora leer los archivos necesarios para iniciar el sistema operativo Windows de la imagen dentro de un archivo VHD. Cuando Windows se inicia desde un archivo VHD, todos los "E / S de disco" para cargar el kernel de los controladores de dispositivo, Sistema de arranque de los servicios, y ejecución de aplicaciones se traduce a I / O para el archivo VHD , y luego de E / S al volumen NTFS y el disco físico. En el apagado, se gestionan todas las operaciones de escritura al mismo nivel que el archivo VHD y partición física subyacente en el orden correcto de la pila de almacenamiento antes de apagar el dispositivo de disco. Debido a estas mejoras de las partes fundamentales del sistema, el arranque nativo desde VHD sólo funciona para VHDs contienen Windows 7 o Windows Server 2008 R2, y no las versiones anteriores de Windows. Esta versión no es compatible con BitLocker, o la hibernación (que incluye la reanudación de la hibernación).
El despliegue de imágenes
Para poner en un equipo con Windows 7 o Windows Server 2008 R2 la imagen del sistema operativo en el archivo VHD, se tiene que aplicar una imagen a la partición en el archivo VHD. Ejecutar el programa de instalación desde el DVD de instalación y la selección de una partición en un archivo VHD para la instalación no es compatible. Aquí hay dos formas de aplicar una imagen WIM VHD:
El script de Powershell-WindowsImage utiliza el wimgapi.dll en Windows 7 al aplicar una WIM a un VHD. Utilice la secuencia de comandos si no está familiarizado con la WAIK y la herramienta Imagex.exe , o no tiene WAIK disponible.
Ver el documento Instalación de Uso-WindowsImage, para las instrucciones paso a paso sobre cómo crear un VHD WIM y aplicar una imagen de arranque a un VHD.
Los profesionales de TI se interesan en el uso de las herramientas de implementación de WAIK para personalizar y captar una imagen de referencia de Windows y desplegar la imagen en formato VHD ya sea a maquinas físicas o máquinas virtuales. El despliegue de medidas básicas para preparar una imagen personalizada de Windows incluye el texto siguiente:
El VHD generalizado con un archivo de imagen puede ser copiado y utilizado en múltiples máquinas virtuales o físicas. Una imagen generalizada es necesaria para evitar errores en el inicio del sistema, porque el hardware del nuevo sistema es diferente, y para evitar tener múltiples copias de Windows de la misma máquina con el mismo SID (nombre y la identidad de seguridad), en la red. Durante el primer arranque de Windows del fichero VHD en otra máquina virtual o física, Windows especializará la imagen para la nueva máquina, configurando dispositivos, y preparándola para la primera utilización. Copiar el archivo de referencia VHD es una manera rápida de obtener un nuevo Windows 7 o Windows Server 2008 R2 para el desarrollo, ensayo, o puesta en producción para los servidores.
Si usted quiere implementar imágenes Windows a varias máquinas, puede aprovechar el servicio de implementación de Windows (WDS) de Windows Server 2008 R2. WDS se refuerza con la posibilidad de añadir archivos de imagen VHD a la imagen del catálogo WDS. El administrador crea grupos de imágenes VHD en WDS para los archivos que están dispuestos a desplegar a las máquinas permitiendo utilizar el arranque desde red, o "arranque PXE". WDS cuando despliega una imagen VHD, el cliente del agente copia el archivo VHD en local y configura el entorno de arranque para arrancar desde este VHD. Todas las aplicaciones y la configuración del sistema se realizan desde el patrón de referencia de la imagen de archivo VHD. Cuando Windows se inicia desde el archivo VHD por primera vez, el sistema se ha especializado como se mencionó anteriormente, para los dispositivos físicos en la máquina objetivo estando ya listo para usar. Eso es muy cómodo y simplifica el despliegue rápido.
Aunque el apoyo al formato nativo VHD y, concretamente, el arranque, abre un montón de escenarios, nuestros objetivos con esta tecnología son bastante específicos: simplificar la gestión de imágenes para los clientes empresariales ayudando a migrar los servidores a máquinas virtuales, y permitir el desarrollo eficiente y las pruebas de software en entorno aislado del medio, ya sea para máquinas físicas o máquinas virtuales. El apoyo a la VHD como formato nativo es uno de los objetivos clave en los escenarios en la empresa, donde el personal de TI está bien versado con diferentes tecnologías de creación de imágenes y herramientas para la gestión de sus clientes y servidores. Un entorno empresarial gestionado también emplea tecnologías como la redirección de carpetas y los perfiles móviles para la gestión de la información del usuario fuera de las imágenes desplegadas VHD. Los desarrolladores apreciarán rápidamente la capacidad de actualizar o sustituir una imagen VHD durante el desarrollo. Los entornos de prueba pueden usar múltiples imágenes VHD y discos diferenciales para un uso más eficiente de las máquinas de pruebas.
Esperemos que este blog de una idea de cómo Windows 7 y Windows Server 2008 R2 soporta VHD como archivos de formato y por qué el formato de imagen común para la física y las máquinas virtuales será interesante para muchos de los entornos del usuario.
Actualización: algunas personas me han preguntado si esta información se aplica a Microsoft Hyper-V Server 2008 R2 también. La respuesta es sí.
Ante la continua aparición de nuevos sistemas operativos y service packs, en los entornos grandes y heterogéneos (no hace falta que sean gigantes, creo que muchos administradores tienen maquinas con W2K, XP, Vista en el mismo entorno) y la prevista a aparición en breve de Windows 7 (se puede descargar la versión Release Candidate Download W7 RC ) hace que las aplicaciones que tenemos instaladas no siempre se puedan mover de una plataforma a otra con facilidad debido a cambios en la arquitectura, diseño, ...
Esto supone cambios en el desarrollo de la aplicación, testear la aplicación o ejecutarla en modo de compatibilidad con lo que esto supone para un entorno de producción o una aplicación desplegada a un gran numero de usuarios.
Para facilitar la gestión del sistema en estos casos tenemos una aplicación dentro de Microsoft Desktop Optimization Pack MDOP llamada MED-V (Microsoft Enterprise Desktop Virtualization) que permite la ejecución de aplicaciones legacy en los nuevos sistemas desplegados en los que es incompatible su ejecución.
La información sobre esta herramienta se puede revisar en:
http://www.microsoft.com/windows/enterprise/products/med-v.aspx
Announcing MDOP 2009 to include MED-V 1.0, App-V 4.5 CU1 and AIS 1.5 Updates
Aquí podéis descargar los manuales y white papers sobre su funcionamiento y empleo.
Básicamente esta herramienta lo que crea es una maquina virtual, en la maquina con un SO incompatible con la aplicación, que permite que la aplicación se ejecute en una plataforma virtual para la que es compatible (W2000, XP), independientemente del SO que esta albergando el cliente Med-V.
El producto esta creado de forma que, en caso de configurarse de este modo, para el usuario es transparente la existencia de una maquina virtual, y los programas se publican en menú inicio como cualquier aplicación local.
La administración se realiza de forma centralizada, mediante una consola de administración y, como casi todas las soluciones de MDOP, tiene un repositorio central para ficheros (en este caso imágenes de maquinas virtuales), una consola de administración y una base de datos para generar reportes y albergar los eventos generados. Se puede controlar mediante políticas y plantillas de seguridad, por lo que resulta sencilla de administrar, mantener y actualizar las imágenes.
Permite varias formas de distribución (incluido a través de DVD de forma que no se precisa trafico de red para su despliegue), solo precisa conexión de red la primera vez que se conecta (esto es configurable permitiendo establecer periodos de reconexión para actualizar seguridad o las imágenes desplegadas).
Una vez desplegado, para el mantenimiento de las maquinas virtuales, emplea Trim Transfer, de forma que solo se transfieren los bloques de datos actualizados, no precisando la descarga de la imagen completa.
Espero haberos dado a conocer una herramienta que simplifique las tareas de administración, ya solo queda que la probéis y comprobéis su utilidad en vuestros entornos.
Hola!
El objetivo de este post es ayudarles a ustedes a saber que logs buscar para resolver problemas en SCCM 2007.
Les adjunto un documento donde se detallan todos los principales componentes de SCCM y todos los logs que ellos poseen.
Este documento les será de utilidad para saber que logs mirar cuando falla un componente en especial y así evitar controlar logs que no tienen que ver con el componente en sí.
Recordad que estamos siempre abiertos a cualquier solicitud de su parte, acérquenos sus consultas e intentaremos escribir material para resolverlas.
Hola de nuevo, se ha lanzado el SP1 de DPM 2007, aquí tenéis una breve explicación de sus nuevas capacidades y donde obtener los ficheros de actualización y mas info.
Service Pack 1 para Microsoft System Center Data Protection Manager (DPM) 2007 proporciona protección continua de datos para aplicaciones de Windows y servidores de archivos que integran a la perfección el uso de disco y cinta, e incluye las siguientes capacidades ampliadas:
Se han introducido capacidades adicionales con el lanzamiento de DPM 2007 Service Pack 1, como por ejemplo: -Fuente de datos locales que permitan la protección de DPM 2007 Service Pack 1 de servidor para que actúe como servidor de una sucursal que ofrece auto-protección y la virtualización de archivos Servicios de alojamiento dentro de una plataforma. -Protección InterForest de dominio que permite grandes clientes empresariales con varios bosques de Active Directory ® ahora aún más flexibilidad en sus despliegues de DPM. -Disposición para un cliente DPML con respuestas bajo demanda de los clientes mejorada para proteger Windows XP y Windows Vista utilizando la misma infraestructura de DPM 2007 que protege a sus servidores. -Capacidades de recuperación de desastres dentro de DPM 2007 SP1 ahora incluyen la habilidad de emplear una nube de vaulting de terceros (SaaS).
Toda esta nueva funcionalidad se basa en las características del paquete de actualización de DPM 2007 'de junio de 2008, que prevé la protección de Windows Server 2008, incluyendo Windows Server 2008, Windows Server 2008 básico, Windows Server 2008 y del estado del sistema BitLocker ™ -- así como nuevas capacidades de cinta y de biblioteca compartida de cintas.
También se esta integrando con SCOM para poder tener una unidad central de administración y control en el entorno.
Se ha observado incremento de la capacidad de trabajo dentro de los avances que promete mantener Data Protection Manager en una trayectoria hacia la mejora de la forma cómo los clientes de Microsoft protegen y recuperan sus aplicaciones para Windows y servidores de archivos con Microsoft siendo la solución central de backup y recuperación.
Para más detalles y podcasts de DPM 2007, consulte la serie de vídeos en el SP1 de TechNet TechNet Edge
Nota: la protección de los guest de Hyper-V depende de una actualización para Hyper-V publicada en enero de 2009. Véase KB 959962 para obtener más detalles
Video demostrando las nuevas capacidades de este Service Pack
Video: What is new in Service Pack 1
Para bajar la versión X86
Download SP1 for x86 systems to get the latest enhancements for your system.
Para la versión X64
Download SP1 for x64 systems to get the latest enhancements for your system.
Hemos tenido algunos casos sobre virtualización de aplicaciones y uno de los pasos a tener siempre en cuenta es la modificación del nivel del log que genera el servidor.
El log es generado por defecto en el servidor y se puede localizar en el fichero sft-server.log file de C:\Program Files\Microsoft System Center App Virt Management Server\App Virt Management Server\logs\ (en alguna versión puede variar esta ruta)
Con el método que adjunto bastara con reiniciar el servicio de Softgrid para que vuelva al nivel normal de log tras finalizar la reproducción de la situación a analizar.
Niveles de log disponible (ve de menos a mas intenso, generando mayor numero de datos):
1. Transactions
2. Fatal Errors
3. Errors (Default)
4. Informational
5. Debug (Verbose)
6. Trace
Para cambiar en nivel de log:
1. Desde las propiedades de App-V Server service:
2. Ir a las propiedades de App-V Server service.
3. Parar el servicio.
4. En los parámetros de inicio añadir -d X (X es el nivel deseado de log).
5. Arrancar el servicio desde la ventana de propiedades del servicio App-V Server.
Si el servicio es reiniciado desde fuera de la ventana de propiedades del servicio o el servidor es reiniciado, los parámetros de inicio son automáticamente limpiados y el nivel de log vuelva a su valor por defecto (3 Errores)
Técnico de soporte Windows.
Hola a tod@s.
Ayer se hizo publica la versión RC de Windows Server R2, esta se encuentra disponible para su descarga y testeo en:
http://www.microsoft.com/WindowsServer2008R2
http://www.microsoft.com/windowsserver2008/en/us/R2-Download.aspx
También se ha hecho publica la versión RC de Hyper-V Server 2008 R2.
Se puede ampliar información en
Ya se pueden testear estas versiones en vuestros sistemas y disfrutar de sus avances en vitalización.
En ocasiones, es posible que necesitemos inventariar los usuarios y/o grupos que tenemos en nuestro Directorio Activo.
En función del método que empleemos para extraer información, puede ser que los resultados obtenidos no sean los correctos o estén incompletos.
Sea, por ejemplo, el grupo big_group (un grupo Global de Seguridad en el dominio) que tiene unos 2000 miembros aproximadamente.
Si intentamos listar los miembros que tiene, obtenemos los siguientes resultados:
dsget group
En este caso, como podemos ver en la captura, la salida de la herramienta no nos devuelve resultados:
ldp.exe
La herramienta ldp.exe trunca los resultados obtenidos, no mostrando la totalidad de miembros del grupo:
Expanding base 'CN=big_group,CN=Users,DC=testdom,DC=local'...
Result <0>: (null)
Matched DNs:
Getting 1 entries:
>> Dn: CN=big_group,CN=Users,DC=testdom,DC=local
2> objectClass: top; group;
1> cn: big_group;
0> member:
1500> member;range=0-1499: CN=user1,CN=Users,DC=testdom,DC=local; CN=user2,CN=Users,DC=testdom,DC=local; CN=user3,CN=Users,DC=testdom,DC=local; CN=user4,CN=Users,DC=testdom,DC=local; CN=user5,CN=Users,DC=testdom,DC=local;...
A través de la herramienta ntdsutil, podemos controlar una serie de parámetros para las políticas LDAP de los DCs del dominio.
Entre otros, tenemos la posibilidad de alterar el valor del parámetro MaxValRange el cual controla el número de valores que se devuelve en una query para cualquier atributo de un objeto en el AD.
Sin embargo, hemos de tener en cuenta diversas consideraciones antes de realizar cualquier cambio en estas políticas:
· Las políticas de LDAP son comunes a todos los DCs del forest. No es posible tener distintos DCs con valores distintos para cada parámetro.
· El hecho de incrementar el número máximo de valores por atributo que nos devuelve un DC (MaxValRange), puede provocar un impacto en el rendimiento de los Controladores de Dominio.
Este valor tomará efecto para todos los atributos de todos los objetos del Directorio Activo, y no sólo para miembros de un grupo o para otro atributo concreto que nos interese.
Tenéis disponible más información sobre el tema aquí:
315071 - How to view and set LDAP policy in Active Directory by using Ntdsutil.exe
http://support.microsoft.com/kb/315071
[…]
• MaxValRange - This value controls the number of values that are returned for an attribute of an object, independent of how many attributes that object has, or of how many objects were in the search result. In Windows 2000, this control is "hard" coded at 1,000. If an attribute has more than the number of values that are specified by the MaxValRange value, you must use value range controls in LDAP to retrieve values that exceed the MaxValRange value. MaxValueRange controls the number of values that are returned on a single attribute on a single object.
Default value:
o Windows 2000 - 1,024
o Windows Server 2003 - 1,500
Como alternativa, y en caso de necesitar un listado de todos los miembros de un grupo (p.ej. de más de 1500 usuarios en Windows Server 2003), os proponemos el uso de scripts para realizar la tarea.
En el siguiente enlace podéis encontrar un ejemplo de implementación de esto:
Scripting Guy: List members of a group
http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr05/hey0419.mspx
[…] It’s easy enough to list all the members of a group; for example, here’s a script that reports back all the members of the Finance Managers group:
Set objGroup = GetObject _ ("LDAP://cn=Finance Managers, ou=Finance, dc=fabrikam, dc=com") For Each strUser on objGroup.Member Wscript.Echo strUser Next
Un saludo a todos,
Javier Rama
Mañana 14 de abril de 2009 dejará de tener soporte la versiones de Windows 2003 con Service Pack 1.
Mañana hará 24 meses en el que el Service Pack 2 de Windows 2003 está disponible para ser descargado. Las políticas del ciclo de vida de los service packs detallan cada cuanto tiempo los productos quedan fuera del soporte.
Lifecycle Supported Service Packs
http://support.microsoft.com/default.aspx?scid=fh;%5bln%5d;lifesupsps
Producto:
Disponible desde:
Service Pack queda sin Soporte:
Windows Server 2003 Service Pack 0 (RTM)
28-May-2003
10-Apr-2007
Windows Server 2003 Service Pack 1
30-Mar-2005
14-Apr-2009
Windows Server 2003 Service Pack 2
13-Mar-2007
24 meses luego del próximo SP*
*Son 24 meses luego del próximo service pack o del fin del ciclo de vida del producto. Puedes obtener más información en el siguiente enlace:
http://support.microsoft.com/lifecycle/default.aspx#service%20pack%20support
Últimamente hemos recibido varios casos donde los equipos todavía seguían el Windows 2003 con Service Pack 1. A todos ellos le hemos comentado que dichos equipos iban a quedar fuera de soporte y de todos ellos han surgido diferentes dudas.
Que sucede si tengo un problema con el equipo y este posee el Service Pack 1?
Lamentablemente el equipo de soporte de Microsoft no va a poder prestar soporte a dicho equipo hasta que el mismo este dentro de soporte.
Microsoft tiene a disposición de todos la descarga del Windows 2003 Service Pack 2 desde el siguiente link:
http://technet.microsoft.com/en-us/windowsserver/bb229701.aspx
Cuál es la mejor alternativa para instalar o distribuir el Service Pack 2?
Existen diferentes alternativas para instalar el Service Pack 2. Dependiendo de su entorno puede optar por las siguientes:
Directamente desde Windows Update http://windowsupdate.microsoft.com/
Utilizando WSUS
Utilizando SMS http://support.microsoft.com/kb/926030
Que precauciones tengo que tener a la hora de instalar el Service Pack 2?
En la siguiente pagina podrán obtener las recomendaciones que deben tener para instalar el Service Pack 2.
http://technet.microsoft.com/en-us/library/cc755981.aspx
Que problemas puedo llegar a tener luego de instalar el Service Pack 2?
No podemos decir a ciencia cierta que problemas puede llegar a tener si actualiza su equipo a Service Pack 2. Microsoft recomienda que luego de actualizar su equipo a Service Pack 2, actualice el mismo también con todos los parches de seguridad y de actualizaciones disponibles.
También tenga en cuenta que sus controladores de terceros pueden no ser compatibles con Windows 2003 Service Pack 2, por lo cual le recomendamos estar en contacto con su proveedor y actualizar los controladores a la versión que el mismo le indique.
Últimamente en nuestro equipo de soporte hemos estado recibiendo muchas consultas y problemas relacionados con WMI. Dado que este componente está siendo utilizado últimamente por varias aplicaciones y cada vez lo será más, creo que va a ser de mucha utilidad para todos la siguiente serie de posts que les presento.
Estarán divididos dado que es mucho material para un solo post.
Cubriremos:
Arquitectura Básica de WMI
Accediendo al repositorio WMI
Pasos Básicos de Troubleshoot de WMI
Troubleshoot de Problemas de Performance de WMI
Hoy comenzaremos con los aspectos básicos de la arquitectura de WMI
Que es el WMI? WMI es un sistema basado en el standard Web-based Enterprise Management (WBEM). Con el podemos acceder a gran cantidad de información almacenada en nuestro sistema operativo Windows. Este acceso a esta información puede ser realizado mediante scripts, .Net (clase system.management) o por líneas de comando.
Podemos dividir la arquitectura de WMI de la siguiente forma:
Como vemos en el punto 2, la estructura de WMI está dividida en 2, el servicio de WMI (winmgmt) y el Repositorio.
El repositorio usa namespace que contienen a su vez sub-namespaces y estos están ordenados en una jerarquía de objetos. Las aplicaciones se conectan primero a un namespace y luego a través de ese namespace puede acceder a los objetos.
El comienzo de estos namespace esta dado desde ROOT/ Luego al iniciar el servicio de WMI se crean namespaces como ROOT/DEFAULT ROOT/CIMV2 . Como vemos en el grafico, el servicio de WMI es el intermediario entre los Providers, las aplicaciones y el repositorio.
Este repositorio aloja información estática de objetos como las clases definidas por los objetos y toda esta información obtenida de los providers cuando el cliente lo requiere.
Un Provider es un objeto COM que controla los objetos de WMI. Este objeto es un componente que puede ser un disco rigido, una tarjeta de red o un servicio. El Provider entrega al WMI la información sobre el objeto y controla los mensajes de los mismos.
Los Providers son una DLL y un fichero Managed Object Format (MOF) que define las clases para el Provider. Los Providers son clasificados por el WMI de acuerdo a lo que realiza el provider.
Clasificaciones
Descripción
Clase
Puede entregar, modificar, eliminar y listar una clase especifica. También soporta las queries realizadas. Por ejemplo el Directorio Activo es un ejemplo de un servicio que también entrega clases.
Instancia
Puede entregar, modificar, eliminar y listar una instancia especifica. Una instancia representa a un objeto. También soporta que se le realicen queries.
Propiedad
Puede entregar y modificar los valores de las propiedades de los objetos.
Metodo
Métodos específicos para clases de un provider.
Evento
Genera eventos de notificaciones.
“Event Consumer”
Crea una relación entre el objeto físico y el objeto lógico para poder crear la notificaciones de eventos.
Por último, debemos hablar de Common Information Model (CIM) y de los ficheros Managed Object Format (MOF).
CIM es un modelo para lenguajes orientados a objetos como C++ y Java. Los desarrolladores de WMI escriben sus clases en lenguaje MOF, una vez que estas clases están estructuradas en MOF, los desarrolladores pueden dar definiciones a las clases.
Esto se hace compilando un fichero MOF en un binario (BMF) e introduciéndola dentro del Windows Driver Model (WDM).
Los Providers se pueden compilar también en MOF y utilizar las APIs de WMI COM para crear la estructura de WMI con sus definiciones.
Finalmente, los Providers pueden usar un compilador MOF (mofcomp.exe) para agregar las clases al repositorio WMI.
Nos vemos en el próximo post
TAGs: WMI arquitectura, basico, providers
Hola, soy Yolanda Muñoz, del equipo de Directorio Activo. En algunas ocasiones, nos hemos encontrado con la necesidad de disminuir la carga de logon en determinados DCs o bien por ser el de menor recursos hardware del Site o porque se encuentre destinado a otro tipo de operaciones/aplicaciones. En estos casos sugerimos implementar las siguientes recomendaciones:
En esta ocasión nos detendremos a explicar la segunda de las recomendaciones:
Como cambiar el “weight” de los registros SRV en DNS: 1. In the Run dialog box, type regedit, and then press ENTER. 2. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. Click Edit, click New, and then click DWORD value. 4. For the new entry name, type LdapSrvWeight, and then press ENTER. (The value name is not case sensitive.) 5. Double-click the entry name you just typed. 6. In the Edit DWORD Value dialog box, select Decimal as the Base option. 7. Enter a value between 0 and 65535 (the recommended value is 10), and then click OK. 8. Click File, and then click Exit to close the registry editor.
Como cambiar el “weight” de los registros SRV en DNS:
1. In the Run dialog box, type regedit, and then press ENTER. 2. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. Click Edit, click New, and then click DWORD value. 4. For the new entry name, type LdapSrvWeight, and then press ENTER. (The value name is not case sensitive.) 5. Double-click the entry name you just typed. 6. In the Edit DWORD Value dialog box, select Decimal as the Base option. 7. Enter a value between 0 and 65535 (the recommended value is 10), and then click OK. 8. Click File, and then click Exit to close the registry editor.
Cuando el valor de “priority” es el mismo para varios DCs, el valor especificado en “weight” determinará el orden en que los servidores van a ser contactados por los clientes. Como cambiar la “priority” de los registros SRV en DNS: 1. In the Run dialog box, type regedit, and then press ENTER. 2. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. Click Edit, click New, and then click DWORD value. 4. For the new entry name, type LdapSrvPriority, and then press ENTER. 5. Double-click the entry name that you just typed. 6. In the Edit DWORD Value dialog box, select Decimal as the Base option. 7. Enter a value between 0 and 65535 (the recommended value is 500), and then click OK. 8. Click File, and then click Exit to close the registry editor.
Cuando el valor de “priority” es el mismo para varios DCs, el valor especificado en “weight” determinará el orden en que los servidores van a ser contactados por los clientes.
Como cambiar la “priority” de los registros SRV en DNS:
1. In the Run dialog box, type regedit, and then press ENTER. 2. In the registry editor, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 3. Click Edit, click New, and then click DWORD value. 4. For the new entry name, type LdapSrvPriority, and then press ENTER. 5. Double-click the entry name that you just typed. 6. In the Edit DWORD Value dialog box, select Decimal as the Base option. 7. Enter a value between 0 and 65535 (the recommended value is 500), and then click OK. 8. Click File, and then click Exit to close the registry editor.
Para que los valores mencionados anteriormente sean efectivos, es necesario reiniciar el servicio de Netlogon (net stop netlogon && net start netlogon). El servicio al iniciar leerá la nueva configuración y actualizará los registros en DNS con los nuevos valores, siempre que las actualizaciones dinámicas estén permitidas en la zona.
Los nuevos valores quedan reflejados tanto en el archivo netlogon.dns (%Systemroot%\System32\config), como en el netlogon.log (%Systemroot%\debug) si el valor DBFlag está establecido a 0x2080FFFF.
- Yolanda Muñoz Muñoz