Ya esta disponible una nueva versión de la herramienta MVMC 3.0 para conversión de maquinas virtuales y discos procedentes de host VMware  a host Hyper-V  y Azure. 

Aquí tenéis un enlace con toda la información.

Microsoft Virtual Machine Converter 3.0 is now available for download

Espero os sea de utilidad

Paloma.-

Buenos días,

Ya está publicado el Cumulative Update3 para Configuration Manager 2012 R2 con novedades en la gestión mediante powershell:

2994331 - Description of Cumulative Update 3 for System Center 2012 R2 Configuration Manager

2999304 - Description of Windows PowerShell changes in Cumulative Update 3 for System Center 2012 R2 Configuration Manager

Espero que os resulte de utilidad.

Un saludo.

Raúl.

Hace poco hemos estado trabajando en un incidente en el que un equipo Windows Server 2008 R2 SP1 comenzaba a utilizar una dirección IP nueva como origen de sus conexiones. Esta nueva dirección se había configurado como IP adicional.

El equipo tenía una dirección IP principal, configurada en su configuración TCP/IPv4 del tipo A.B.C.50.

El equipo tenía también varias direcciones IP adicionales en la configuración avanzada TCP/IPv4. Estas direcciones iban desde la A.B.C.51 a la A.B.C.63.

A su vez, otro servidor similar tenía la misma configuración, pero con las direcciones: A.B.C.80 (principal) y A.B.C.81-A.B.C.93 (adicionales)

Ambos servidores publicaban diversos sitios web en cada una de esas direcciones IP adicionales. Por delante de ellos, un balanceador de carga enviaba el tráfico a cada IP de dicha pareja. Por ejemplo www.contoso.com era balanceado entre las direcciones A.B.C.51 y la A.B.C.81 (una de cada servidor web).

A su vez, dichos servidores web tenían que conectarse a otros servidores. Estas conexiones salían con la dirección IP origen principal de cada uno de los servidores. En el servidor destino A.B.C.100 se esperaba que las conexiones llegasen con las direcciones IP origen A.B.C.50 y la A.B.C.80.

El problema surgió al añadir una nueva pareja de direcciones IP para publicar un nuevo sitio web. Se optó por mantener la lógica, asignando:

• webserver1 – nueva IP A.B.C.64

• webserver2 – nueva IP A.B.C.94

Al añadir dicha IP nueva en el webserver1, el servidor comenzaba a utilizar esta IP A.B.C.64 como origen de las conexiones que iniciaba hacia el servidor destino, en lugar de la IP configurada como principal A.B.C.50.

Solución corta

La solución al problema pasa por añadir las direcciones IP por línea de comandos con la herramienta netsh y utilizando la opción SkipAsSource=true. Más información: https://support.microsoft.com/kb/975808

Explicación detallada

El comportamiento que tenemos en este entorno viene derivado del mecanismo de selección de la IP origen. En este artículo se explica muy bien:

https://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx

Windows XP behavior

(…)

If a source IP is not given the Primary IP address of the adapter with a route that most closely matches the target IP address is used to source the packet and the adapter that the Primary IP is associated with is used as the source adapter.

Windows Vista/Windows Server 2008 behavior

Windows Vista and later are based on the strong host model. In the strong host model, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. Also the concept of a primary IP address does not exist.

Similar to XP when if a program doesn't specify a source IP, the stack references the target IP address, and then examines the entire IP route table so that it can choose the best network adapter over which to send the packet. After the network adapter has been chosen, the stack uses the address selection process defined in RFC 3484 and uses that IP address as the source IP address for the outbound packets.

Y en concreto, esa implementación del RFC 3484 es la siguiente (la parte que nos interesa es la Rule8a):

Windows Source IP V4 address selection:

• Rule 1 Prefer same address (applies)

• Rule 2 Prefer appropriate scope (applies)

• Rule 3 Avoid deprecated addresses (applies)

• Rule 4 - Prefer home addresses - does not apply to IP v4

• Rule 5 Prefer outgoing Interfaces (applies)

• Rule 6 Prefer matching label - does not apply to IP v4

• Rule 7 Prefer public addresses - does not apply to IP v4

• Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!)

  • If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA

  • Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB.

  • This says that the IP with the most high order bits that match the destination of the next hop will be used.

• Note: Rule 8 - Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address.

En este caso particular, el problema no era trivial, ya que justo el rango de direcciones IP definido es lo que estaba provocando este cambio de comportamiento. Haciendo los cálculos en base al algoritmo anterior, tenemos lo siguiente:

Cálculos iniciales

• El servidor de destino con el que fallaba el tráfico tenía la IP A.B.C.100

  100 decimal = 0110 0100 binario

• Selección de la IP origen - los 3 primeros octetos de la IP son siempre los mismos (A.B.C) por lo que solo hacemos los cálculos en binario para el último octeto. Algunos ejemplos:

  • Caso 1: Primera dirección IP del rango que tiene el servidor:

    • A.B.C.50 decimal = 0011 0010 binario

  • Caso 2: Última IP que al añadirla ha provocado el problema:

    • A.B.C.64 decimal = 0100 0000 binario

  • Caso 3: Última IP con la que se comportaba bien el servidor:

    • A.B.C.63 decimal = 0011 1111 binario

Según el algoritmo:

• "If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA.

• Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. "

Es decir, para los ejemplos anteriores tenemos:

Caso 1:

Source A (SA) = A.B.C.50

Source B (SB) = A.B.C.64

CommonPrefixLen(SA, D) = CommonPrefixLen(a.b.c.50, a.b.c.100) -- 25 bits (3 octetos + 1 bit del 4º octeto)

CommonPrefixLen(SB, D) = CommonPrefixLen(a.b.c.64, a.b.c.100) -- 26 bits (3 octetos + 2 bits del 4º octeto)

Resultado: La IP .64 tiene un prefijo común mayor con la dirección IP destino .100, por lo que se usa dicha IP .64 como origen.

Caso 2:

Source A (SA) = A.B.C.50

Source B (SB) = A.B.C.63

CommonPrefixLen(SA, D) = CommonPrefixLen(a.b.c.50, a.b.c.100) -- 25 bits (3 octetos + 1 bit del 4º octeto)

CommonPrefixLen(SB, D) = CommonPrefixLen(a.b.c.63, a.b.c.100) -- 25 bits (3 octetos + 1 bits del 4º octeto)

Resultado: Las dos direcciones IP tienen el mismo prefijo común, por lo que en este caso, se utiliza la IP menor de ambas (en este caso A.B.C.50). Este resultado es el mismo para todos los casos en los que Source B esté entre A.B.C.51 y A.B.C.63.

 El cambio de comportamiento se produce a partir de la IP 64 ya que el bit 7 del último octeto pasa a estar activo (0100 0000), algo que no ocurría en las direcciones inferiores (<=63). Ese bit 7 también está activo en la IP destino D (.100), por lo que el CommonPrefixLen empieza a ser mayor, y se selecciona esa IP como source IP.

 Espero que este artículo os haya resultado interesante.

Un saludo,

Sergio Medina Vallejo – Support Escalation Engineer – Microsoft Global Business Support

 2970177 - Description of Cumulative Update 2 for System Center 2012 R2 Configuration Manager

2962855 - Description of Windows PowerShell changes in Cumulative Update 2 for System Center 2012 R2 Configuration Manager

 2976481 - Description of Cumulative Update 2 for the System Center 2012 R2 Configuration Manager Clients for Linux and Unix

Creo que os resultara interesante.

 Un saludo.

Raúl.

Tuve un caso bastante curioso que puede evitar más de un quebradero de cabeza en algunos entornos.

En el site server comenzaron a aparecer eventos como el siguiente:

Site Component Manager detected that the site server does not contain the binary files for the platform (processor architecture) of site system "\\servername".

Possible cause: When installing this site, you did not specify that the binary files for this site system's platform should be installed on the site server.

Solution: Use Configuration Manager Setup to modify the configuration of this site. When asked to select the server platforms for this site, select this site system's platform.

Possible cause: You accidently configured the site to use the wrong computer as a site system.

Solution: Remove this site system from the list of site systems for this site, and add the correct site system to the list. The list appears in the Site Systems node of the Configuration Manager Console.

Possible cause: The site system is turned off, not connected to the network, or not functioning properly.

Solution: Verify that the site system is turned on, connected to the network, and functioning properly.

Possible cause: Site Component Manager does not have sufficient access rights to remotely administer the site system.

Solution: Verify that the Site System Installation accounts are properly configured to allow the site to remotely administer the site system.

Possible cause: Network problems are preventing Site Component Manager from properly accessing to the site system.

Solution: Investigate and correct any problems on your network.

También localizamos que un montón de servidores no podían arrancar el smsexec en la consola de SCCM y que no podían ser administrados:

Tras revisar estas máquinas tenían en común que eran todas máquinas de arquitectura x86 y que tenían el role de Distribution Point, pero, ¿Por qué se está estaban generando estos eventos respecto a la arquitectura?

Tras comprobar que roles tenían añadidos localizamos que, además del role de Distribution Point, tenían añadido el de State Migration Point (SMP), como se puede comprobar en el siguiente articulo el único role soportado en SCCM 2012 R2 sobre equipos con arquitectura x86 es el de Distribution point:

Supported Configurations for Configuration Manager,

Each System Center 2012 Configuration Manager site system server must use a 64-bit operating system. The only exception to this is the distribution point site system role which can be installed on limited 32-bit operating system versions.

La solución fue quitar el role de SMP a todas estas máquinas y la situación fue resuelta.

Espero que esto os resulte de utilidad.

Raul Del Moral Guirado

Buenos días,

Probablemente bastantes de vosotros ya estéis al tanto, pero el pasado día 28 de Marzo se hizo público el CU1 para la versión de Configuration Manager 2012 R2, el cual además añade opciones nuevas para la gestión mediante Powershell.

La información detallada sobre este Cumulative Update la tenéis disponible en:

Description of Cumulative Update 1 for System Center 2012 R2 Configuration Manager

Description of PowerShell changes available in Cumulative Update 1 for System Center 2012 R2 Configuration Manager

Un saludo

Raúl

Buenos días,

Se han publicado una seria de E-Books gratuitos sobre SCCM 2012 R2, para los que estén interesados en su consulta están disponibles en:

https://blogs.technet.com/b/configurationmgr/archive/2014/03/05/free-ebook-microsoft-system-center-configuration-manager-field-experience.aspx

https://blogs.technet.com/b/configurationmgr/archive/2014/02/26/free-ebook-microsoft-system-center-troubleshooting-configuration-manager.aspx

Descargables desde:

https://www.microsoftvirtualacademy.com/ebooks#?fbid=ALIEEXWpfqU

Espero que os resulte de utilidad.

Un saludo.

Raúl.

En nuestra documentación en TechNet se recomienda el empleo de una base de datos compartidas en SCCM 2012 cuando se tienen varios SUP en el mismo site, pero no estaba claro el nivel de soporte para esta configuración desde un punto de vista de SUS services o que pasos son necesarios para su configuración, ya que únicamente estaba documentado como configurar WSUS con una base de datos compartida en un cluster NLB de servidores WSUS.

Últimamente hemos tenido algunos casos de soporte con situaciones donde se consultaba el nivel de soporte de esta configuración o errores en la gestión de los ficheros EULA en algunos updates de Internet Explorer (este tipo de ficheros tienen una gestión distinta al resto de updates en entornos con SUP en SCCM).

Finalmente tenemos la documentación confirmando el soporte de esta configuración y los pasos a seguir para su correcto funcionamiento:

https://blogs.technet.com/b/wsus/archive/2014/03/22/considerations-for-multiple-wsus-instances-sharing-a-content-database-when-using-system-center-configuration-manager-but-without-network-load-balancing-nlb.aspx

To set up such a configuration, you would install multiple SCCM SUPs with WSUS on shared database, configure WSUS/SUP to store content on a file share, but stopping short of enabling NLB.

1. Install SQL

1. Install first WSUS server creating database

1. Install other WSUS servers creating database

1. Create share for content (computer accounts must have change permission)

1. On first WSUS server Use WSUSutil movecontent to change location

1. On each WSUS server, in IIS ensure the “Content” virtual directory path is set to the share, and specify an account to use to connect to the path (to cater for anonymous access).

1. Add SUP (Software Update Point) role to first server and synch.

1. Add SUP role to other servers.

Rather than connecting to WSUS directly, clients are choosing a random SUP to connect to (which is their expected behavior, and why the NLB is not needed on the server side). This is a supported configuration of WSUS, but only when WSUS is being used in a SCCM deployment.

Espero que esta información os resulte de utilidad.

Un saludo.

Raúl.

Hola,

He tenido un caso bastante curioso, que implica Windows 2003 Sp2 (el Soporte termina bastante más tarde que XP, será el 14 de Julio del 2015) en entornos con SCCM 2012 R2.

En esta configuración podemos encontrar que el cliente se instala correctamente en el servidor, pero este no es manejado (tenemos el servicio SMS Agent Host ejecutándose pero no tenemos policies o actividad en el cliente)

En el repositorio de certificados del cliente, en SMS, tenemos los certificados correctamente descargados en el cliente.

Entonces, ¿Por qué no podemos establecer el canal con el Management Point para la descarga de políticas de SCCM?

En el CertificateMaintenance.log vemos:

Failed to verify signature of message received from MP using name 'Machine.Domain.local']LOG]!><time="16:42:17.635-60" date="03-27-2014" component="CertificateMaintenance" context="" type="3" thread="2168" file="hookimpl.cpp:181">

En  ClientIDMAnagerStartup.log:

RegTask: Failed to send registration request message. Error: 0x87d00309]LOG]!><time="16:42:17.635-60" date="03-27-2014" component="ClientIDManagerStartup" context="" type="3" thread="2168" file="regtask.cpp:1322">

<![LOG[RegTask: Failed to send registration request. Error: 0x87d00309]LOG]!><time="16:42:17.635-60" date="03-27-2014" component="ClientIDManagerStartup" context="" type="3" thread="2168" file="regtask.cpp:1508">

<![LOG[[RegTask] - Sleeping for 15360 seconds ...]LOG]!><time="16:42:17.635-60" date="03-27-2014" component="ClientIDManagerStartup" context="" type="1" thread="2168" file="regtask.cpp:1445">

Y en clientAuth.log:

<![LOG[Client attempts to send a message without Client GUID]LOG]!><time="09:25:37.812-60" date="03-21-2014" component="ClientAuth" context="" type="3" thread="2064" file="clientauthhook.cpp:209">

<![LOG[Error signing client message (0x87d00224).]LOG]!><time="09:25:37.812-60" date="03-21-2014" component="ClientAuth" context="" type="3" thread="2064" file="clientauthhook.cpp:376">

Pero el log que indica realmente que está ocurriendo con el cliente es CertificateMaintenance.log:

 Failed to verify signature of message received from MP using name machine.domain.local' CertificateMaintenance 21/03/2014 11:38:49 2168 (0x0878)

 Este error significa:

CRYPT_E_UNKNOWN_ALGO

Unknown cryptographic algorithm.

 La solución está en la versión de cryp32.dll instalada en la maquina, si esta es antigua no es capaz de decodificar la informacion recibida del Management Point, con lo que se genera el evento.

En nuestro caso se solucionó con la instalación del siguiente KB:

 https://support.microsoft.com/kb/2868626/en-US

Un saludo,

Raúl.

 En uno de nuestros alias internos ha surgido una pregunta que creo que resultara de interés para la comunidad.

 ¿Entre las opciones de migración está la de migrar datos entre versiones de SCCM 2012, es decir, datos desde un SCCM 2012 SP1 a un 2012 R2?

 La respuesta está indicada en el siguiente artículo, pero en algunos casos puede llevar a dudas, con lo que lo aclaro a continuación.

 https://technet.microsoft.com/en-us/library/gg699364.aspx#BKMK_MigrationScenarios

Este tipo de migración no está soportada, solo se pueden migrar datos entre 2012 de la misma versión, de SP1 a SP1 o de R2 a R2, no está soportada la migración de datos entre diferentes versiones.

 Se ha solicitado añadir esta aclaración a la documentación, ya que es una pregunta que parece que se realiza en soporte con cierta frecuencia.

Un saludo, Raul.-