New MsiCleanUp Utility

Who has not had problems with programs that are not uninstalled correctly? Usually as a result the software after this error cannot be reinstalled.

So far we had MsiCleanUp, but is no longer officially available.

What option do we have now?

Since a few months Microsoft released a fixit that is supposed to be responsible for these situations (if you read the whole article just seems to be designed for Visio, but I tried it with some others and sometimes it works), so is worth it to give it a try.

It is available for download at:

https://support.microsoft.com/en-us/mats/program_install_and_uninstall

I hope you find it helpful.

Nuevo MsiCleanUp

¿Quien no ha tenido problemas con Programas que no se desinstalan correctamente? Normalmente como consecuencia luego este software no puede ser reinstalado.

Hasta ahora teniamos MsiCleanUp, pero ya no se encuentra disponible oficialmente.

¿Que opción tenemos entonces ahora?

Pues desde unos meses Microsoft publico un fixit que se supone que se encarga de estas situaciones (si leemos todo el articulo solo parece estar diseñado para Visio, pero lo probé con algún otro y a veces funciona), es recomendable probarlo.

Esta disponible para su descarga en:

https://support.microsoft.com/en-us/mats/program_install_and_uninstall

Espero que os resulte de utilidad.

Actualizando W7 tras el 10 de mayo

No todos los entornos pueden estar con la última versión del sistema operativo en producción (ahora W10), se necesita un tiempo de testeo, validación, migración, …

Esto supone que en muchos entornos la imagen que se despliega es W7, pero, ¿se esta aplicando una política de mantenimiento sobre esta imagen, actualizándola con DCIM, o simplemente se aplica la imagen limpia, y se actualiza una vez aplicada sobre la máquina cliente?

Para estos últimos se puede descargar desde 3125574 este llamado rollup de conveniencia, tienes más información sobre este update en https://support.microsoft.com/en-us/kb/3125574., en resumen este update contiene todos los updates, que no sean fixes, hasta abril de 2016, con lo que actualizamos la imagen en un solo paso.

Si queremos aplicarselo a nuestro despliegue tendremos dos opciones, aplicarlo mediante DCIM (tened en cuenta que para que se pueda aplicar con este medio precisamos aplicar/inyectar antes el update KB3020369 ), o añadirlo a la secuencia de instalación para que se aplique durante el primer arranque de la máquina.

De esta forma evitamos la instalación de esos más de 200 updates trás el primer inicio, con varios reinicios que retrasan la ejecución de la imágen, y por consiguiente de la maquina ya actualizada.

 

Espero que esta información os resulte de utilidad.

Managing W7 images after 10th of May

Not all environments can be with the latest version of the operating system on production (now W10), it takes some time for testing, validation, migration, …

This means that in many environments the image deployed is W7, but do you have a policy for maintaining this image, updating it with DCIM, or just the clean image is applied, and is updated once applied on the client machine ?

For the latter ones may be downloaded and applied this named convenience rollup KB3125574 , you have more information about this update in https://support.microsoft.com/en-us/kb/3125574, basically contains all updates, not fixes, published for W7 till April 2016.

If we apply it to our deployment we have two options, apply by DCIM (please note that you can apply this means we need to apply / inject before the update KB3020369), or add it to the installation sequence to be applied for the first boot the machine.

This way we avoid the installation of these more than 200 updates applied after the first start, with several restarts that delay the execution of the image, and therefore the completion of the updated machine.

I hope this information proves useful to you.

El cliente ConfigMgr y los métodos WMI

El cliente de ConfigMgr controla las acciones a realizar en la máquina llamando a métodos WMI, lo podemos confirmar en el log scheduler.log donde podemos ver algunas de ellas.

 

Sending message for schedule ‘Machine/{00000000-0000-0000-0000-000000000021}’ (Target: ‘direct:PolicyAgent_RequestAssignments’, Name: ”)        Scheduler        22/05/2016 20:17:45        9072 (0x2370)

 

Por lo tanto, aparte de las acciones de la consola del cliente en el panel de control, podemos realizar otras muchas acciones que no aparecen en ella indicada, incluso llamar otros metodos WMI que pueden ayudarnos en la solucion de problemas, como podemos ver en este pantallazo de WMIExplorer:

Para lanzar estas acciones bastará llamar a los metodos WMI que los inician, esto podremos hacerlo desde wmiconfig, el cmd mediante wmic, o desde powershell, segun el grado de posible automatización que deseemos añadir, eso sí, recordad que tenemos impersonar la cuenta local de sistema, por lo que necesitaremos psexec para lanzar un cmd/powershell con este usuario.

 

Por ejemplo:

psexec -i -d -s c:\windows\cmd.exe

psexec -i -d -s %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

 

Los métodos para las acciones disponibles están documentados en:

https://blogs.technet.microsoft.com/charlesa_us/2015/03/07/triggering-configmgr-client-actions-with-wmic-without-pesky-right-click-tools/

 

Pero aquí sólo aparecen métodos con WMIC, encontré otro post con ejemplos para PowerShell de forma que sea posible automatizarlo, o incluso crear herramientas con ello, sin necesidad del SDK (ejemplo con hardware inventory y una variable $computer que da mas flexibilidad al script, también podemos crear una variable $strMethod para flexibilizar las acciones a realizar):

 

 

ref: http://myitforum.com/articles/40/view.asp?id=11731

$strComputer = “”

$SMSCli = [wmiclass] “\\$strComputer\root\ccm:SMS_Client”

$SMSCli.TriggerSchedule(“{00000000-0000-0000-0000-000000000001}”)

 

 

$strComputer = “”

$strMethod = “”

$SMSCli = [wmiclass] “\\$strComputer\root\ccm:SMS_Client”

$SMSCli.TriggerSchedule(“{$strMethod}”)

 

$strComputer = “computername”

$strMethod = “{00000000-0000-0000-0000-000000000001}”

$SMSCli = [wmiclass] “\\$strComputer\root\ccm:SMS_Client”

$SMSCli.TriggerSchedule(“$strMethod”)

 

 

Los métodos disponibles para lanzar son:

 

{00000000-0000-0000-0000-000000000001} Hardware Inventory

{00000000-0000-0000-0000-000000000002} Software Inventory

{00000000-0000-0000-0000-000000000003} Discovery Inventory

{00000000-0000-0000-0000-000000000010} File Collection

{00000000-0000-0000-0000-000000000011} IDMIF Collection

{00000000-0000-0000-0000-000000000012} Client Machine Authentication

{00000000-0000-0000-0000-000000000021} Request Machine Assignments

{00000000-0000-0000-0000-000000000022} Evaluate Machine Policies

{00000000-0000-0000-0000-000000000023} Refresh Default MP Task

{00000000-0000-0000-0000-000000000024} LS (Location Service) Refresh Locations Task

{00000000-0000-0000-0000-000000000025} LS (Location Service) Timeout Refresh Task

{00000000-0000-0000-0000-000000000026} Policy Agent Request Assignment (User)

{00000000-0000-0000-0000-000000000027} Policy Agent Evaluate Assignment (User)

{00000000-0000-0000-0000-000000000031} Software Metering Generating Usage Report

{00000000-0000-0000-0000-000000000032} Source Update Message

{00000000-0000-0000-0000-000000000037} Clearing proxy settings cache

{00000000-0000-0000-0000-000000000040} Machine Policy Agent Cleanup

{00000000-0000-0000-0000-000000000041} User Policy Agent Cleanup

{00000000-0000-0000-0000-000000000042} Policy Agent Validate Machine Policy / Assignment

{00000000-0000-0000-0000-000000000043} Policy Agent Validate User Policy / Assignment

{00000000-0000-0000-0000-000000000051} Retrying/Refreshing certificates in AD on MP

{00000000-0000-0000-0000-000000000061} Peer DP Status reporting

{00000000-0000-0000-0000-000000000062} Peer DP Pending package check schedule

{00000000-0000-0000-0000-000000000063} SUM Updates install schedule

{00000000-0000-0000-0000-000000000071} NAP action

{00000000-0000-0000-0000-000000000101} Hardware Inventory Collection Cycle

{00000000-0000-0000-0000-000000000102} Software Inventory Collection Cycle

{00000000-0000-0000-0000-000000000103} Discovery Data Collection Cycle

{00000000-0000-0000-0000-000000000104} File Collection Cycle

{00000000-0000-0000-0000-000000000105} IDMIF Collection Cycle

{00000000-0000-0000-0000-000000000106} Software Metering Usage Report Cycle

{00000000-0000-0000-0000-000000000107} Windows Installer Source List Update Cycle

{00000000-0000-0000-0000-000000000108} Software Updates Assignments Evaluation Cycle

{00000000-0000-0000-0000-000000000109} Branch Distribution Point Maintenance Task

{00000000-0000-0000-0000-000000000110} DCM policy

{00000000-0000-0000-0000-000000000111} Send Unsent State Message

{00000000-0000-0000-0000-000000000112} State System policy cache cleanout

{00000000-0000-0000-0000-000000000113} Scan by Update Source

{00000000-0000-0000-0000-000000000114} Update Store Policy

{00000000-0000-0000-0000-000000000115} State system policy bulk send high

{00000000-0000-0000-0000-000000000116} State system policy bulk send low

{00000000-0000-0000-0000-000000000120} AMT Status Check Policy

{00000000-0000-0000-0000-000000000121} Application manager policy action

{00000000-0000-0000-0000-000000000122} Application manager user policy action

{00000000-0000-0000-0000-000000000123} Application manager global evaluation action

{00000000-0000-0000-0000-000000000131} Power management start summarizer

{00000000-0000-0000-0000-000000000221} Endpoint deployment reevaluate

{00000000-0000-0000-0000-000000000222} Endpoint AM policy reevaluate

{00000000-0000-0000-0000-000000000223} External event detection

 

Espero que os resulte de utilidad.

ConfigMgr Client and WMI methods

ConfigMgr client controls the actions to be performed on the machine calling WMI methods, we can confirm this on the log scheduler.log, where we can see some of them.

 

Sending message for schedule ‘Machine / {00000000-0000-0000-0000-000000000021}’ (Target: ‘direct: PolicyAgent_RequestAssignments’ Name ”) Scheduler 5/22/2016 20:17:45 9072 (0x2370)

Therefore, apart from the actions of the client console in the control panel, you can perform many other actions that do not appear in it indicated, or even call other methods that allow some troubleshooting on the client (review on WMI as this may depend on the client version), the options on my lab shown with WMIExplorer:

To launch these actions you may call WMI methods, you can do so from wmiconfig, cmd by calling wmic, or from PowerShell, according to the degree of automation you want to add, but please, remember that we need  impersonating local account system, so we need psexec to launch a cmd/powershell with this user.

 

For example:

psexec -i -d -s c:\windows\cmd.exe

psexec -i -d -s %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

 

Methods available are documented at:

https://blogs.technet.microsoft.com/charlesa_us/2015/03/07/triggering-configmgr-client-actions-with-wmic-without-pesky-right-click-tools/

 

But here only appear how to call WMIC methods , I found another post with PowerShell examples, so we may have some kind of automation, or even create tools without SDK (example inventory hardware and a variable $strComputer which gives more flexibility to the script, we can also create a variable $strMethod to relax the actions to be taken):

 

ref: http://myitforum.com/articles/40/view.asp?id=11731

$strComputer = “”

$SMSCli = [wmiclass] “\\$strComputer\root\ccm:SMS_Client”

$SMSCli.TriggerSchedule(“{00000000-0000-0000-0000-000000000001}”)

 

$strComputer = “”

$strMethod = “”

$SMSCli = [wmiclass] “\\$strComputer\root\ccm:SMS_Client”

$SMSCli.TriggerSchedule(“{$strMethod}”)

 

$strComputer = “computername”

$strMethod = “{00000000-0000-0000-0000-000000000001}”

$SMSCli = [wmiclass] “\\$strComputer\root\ccm:SMS_Client”

$SMSCli.TriggerSchedule(“$strMethod”)

 

The methods available are:

 

{00000000-0000-0000-0000-000000000001} Hardware Inventory

{00000000-0000-0000-0000-000000000002} Software Inventory

{00000000-0000-0000-0000-000000000003} Discovery Inventory

{00000000-0000-0000-0000-000000000010} File Collection

{00000000-0000-0000-0000-000000000011} IDMIF Collection

{00000000-0000-0000-0000-000000000012} Client Machine Authentication

{00000000-0000-0000-0000-000000000021} Request Machine Assignments

{00000000-0000-0000-0000-000000000022} Evaluate Machine Policies

{00000000-0000-0000-0000-000000000023} Refresh Default MP Task

{00000000-0000-0000-0000-000000000024} LS (Location Service) Refresh Locations Task

{00000000-0000-0000-0000-000000000025} LS (Location Service) Timeout Refresh Task

{00000000-0000-0000-0000-000000000026} Policy Agent Request Assignment (User)

{00000000-0000-0000-0000-000000000027} Policy Agent Evaluate Assignment (User)

{00000000-0000-0000-0000-000000000031} Software Metering Generating Usage Report

{00000000-0000-0000-0000-000000000032} Source Update Message

{00000000-0000-0000-0000-000000000037} Clearing proxy settings cache

{00000000-0000-0000-0000-000000000040} Machine Policy Agent Cleanup

{00000000-0000-0000-0000-000000000041} User Policy Agent Cleanup

{00000000-0000-0000-0000-000000000042} Policy Agent Validate Machine Policy / Assignment

{00000000-0000-0000-0000-000000000043} Policy Agent Validate User Policy / Assignment

{00000000-0000-0000-0000-000000000051} Retrying/Refreshing certificates in AD on MP

{00000000-0000-0000-0000-000000000061} Peer DP Status reporting

{00000000-0000-0000-0000-000000000062} Peer DP Pending package check schedule

{00000000-0000-0000-0000-000000000063} SUM Updates install schedule

{00000000-0000-0000-0000-000000000071} NAP action

{00000000-0000-0000-0000-000000000101} Hardware Inventory Collection Cycle

{00000000-0000-0000-0000-000000000102} Software Inventory Collection Cycle

{00000000-0000-0000-0000-000000000103} Discovery Data Collection Cycle

{00000000-0000-0000-0000-000000000104} File Collection Cycle

{00000000-0000-0000-0000-000000000105} IDMIF Collection Cycle

{00000000-0000-0000-0000-000000000106} Software Metering Usage Report Cycle

{00000000-0000-0000-0000-000000000107} Windows Installer Source List Update Cycle

{00000000-0000-0000-0000-000000000108} Software Updates Assignments Evaluation Cycle

{00000000-0000-0000-0000-000000000109} Branch Distribution Point Maintenance Task

{00000000-0000-0000-0000-000000000110} DCM policy

{00000000-0000-0000-0000-000000000111} Send Unsent State Message

{00000000-0000-0000-0000-000000000112} State System policy cache cleanout

{00000000-0000-0000-0000-000000000113} Scan by Update Source

{00000000-0000-0000-0000-000000000114} Update Store Policy

{00000000-0000-0000-0000-000000000115} State system policy bulk send high

{00000000-0000-0000-0000-000000000116} State system policy bulk send low

{00000000-0000-0000-0000-000000000120} AMT Status Check Policy

{00000000-0000-0000-0000-000000000121} Application manager policy action

{00000000-0000-0000-0000-000000000122} Application manager user policy action

{00000000-0000-0000-0000-000000000123} Application manager global evaluation action

{00000000-0000-0000-0000-000000000131} Power management start summarizer

{00000000-0000-0000-0000-000000000221} Endpoint deployment reevaluate

{00000000-0000-0000-0000-000000000222} Endpoint AM policy reevaluate

{00000000-0000-0000-0000-000000000223} External event detection

 

I hope that this have been informative for you.

DRS Introduction

One of the biggest changes that occurred in the design of ConfigMgr about SCCM / SMS was the conception of a new way of data management and replication between sites, both central to the primary, and primary with secondary adding SQL Service Broker, and not only replication files.

This meant that, previously to SP1, in ConfigMgr you had to define in the design phase if you wanted a single site, or may needed more, so creating a Central Site (CAS) was needed, and this role could not be added at a later point unless the entire site is rebuilt.

This resulted in the creation of Central Sites for the sole purpose of having them if were needed in the future, which is not desired in the design of any solution.

This change in SP1 and design allow to add this central site subsequently, giving flexibility to the design.

But why this limitation? What had changed?

SMS/SCCM replication was based on files, the Management Point sent the file to the Primary, this processing the file, if it depended on another site, these same files were sent sequentially until reach the highest level of the hierarchy, as is visible the level of performance on this design does not scale well and generates that the same file is processed several times in the structure generating redundancies that are not helping performance.

On ConfigMgr this was changed so that the file processed in the Primary Site is added to the database, and the information is replicated to the other sites via SQL-based replication, so is only processed one time, but this is not based on the native SQL replication, it is a service designed and created by the group ConfigMgr product.

And then, what is this replication?

Let’s start by defining what type of data is replicated, these are:

Global Data. Is the data of the database that are replicated between the CAS and all sites, applying to all sites, for example, boundaries, setting site, update Ids, … generally the data we see in the console and are common to all sites.

An offshoot of this is the Global Proxy Data, which are the primary replicates data to its side.

Site data. Is the data only apply to the local site, such as inventory, … are data that are not common among the sites only replicated between the primary site and the CAS.

This is the basis for understanding replication, since these data are replicated in groups according to whether global or site, forming replication groups.

When you install a new site this replication need to follow a few steps to initialize, would be:

a. Replication begins with a file BulkCopy actually tables that form replication groups from the parent server to the database server child by a bcp copy of the database is copied.

b. After this copy file replication can start, and using SQL elements, the changes that occur in the database, for this port 4022 is used by default (it is now configurable)

After this mounted replication, exchange controls now in the databases will feed data to replicate.

What if replication fails?

They have several automatic actions on the site, if none of these works need to act to repair it.

We cannot leave much time this component unattended because it has a limit lifetime of the data, if it passes this time (5 days by default), the entire process will restart with a new BulkCopy, moving a large volume of data In the net.

But this part and to another post.

Introdución a DSR en ConfigMgr

Uno de los mayores cambios que se produjo en el diseño de ConfigMgr respecto a SCCM/SMS fue la concepción de una nueva forma de gestión de los datos y replicación entre los sites, tanto el central con el primario, como el primario con los secundarios basado en SQL Service Broker, y no solo en la replicación mediante ficheros.

 

Esto tuvo como consecuencia que, previamente el SP1, en ConfigMgr se tenía que definir en la fase de diseño si se deseaba un solo site, o se precisaban varios, con lo que se necesitaba la creación de un Sitio Central (CAS), y este role no se podía añadir a menos que se reconstruyera todo el site.

Esto dio lugar a la creación de Central Sites con el único objeto de tenerlos por si eran necesarios en un futuro, lo cual no es deseado en el diseño de ninguna solución.

Esto cambio en el SP1 y se modificó el diseño para poder añadir este sitio central posteriormente, lo que dio flexibilidad al diseño.

 

¿Pero por qué esta limitación? ¿Qué había cambiado?

 

En SMS/SCCM la replicación estaba basada en ficheros, es decir, el Management Point enviaba el fichero al Primario, y este procesaba el fichero, si este dependía de otro site, estos mismos ficheros se enviaban de forma secuencial hasta llegar al nivel más alto de la jerarquía, como es visible, a nivel de rendimiento este diseño no escala bien y genera que el mismo fichero sea procesado varias veces en la estructura generando redundancias que no están ayudando al rendimiento.

 

En ConfigMgr esto se cambió, de forma que el fichero es procesado en el Primary sSite, añadido a la base de datos, y la información es replicada al resto de sites a través de replicación basada en SQL, pero no es la replicación nativa de SQL, es un servicio diseñado y creado por el grupo de producto de ConfigMgr.

 

Y entonces, ¿en qué consiste esta replicación?

 

Vamos a comenzar por definir qué tipo de datos se replican, esto son:

Global Data. Son los datos de la base de datos que son replicados entre el CAS y todos los sites, aplicando a todos los sites, por ejemplo, boundaries, configuración del site, update Ids, … en general los datos que vemos en la consola y que son comunes a todos los sites.

Una derivación de esto es el Global Proxy Data, que son los datos que el primario replica con sus secundarios.

Site data. Son los datos que solo aplican al site local, por ejemplo inventario, … son datos que no son comunes entre los sites, solo se replican entre el site primario y el CAS.

 

Esta es la base para entender la replicación, ya que estos datos se replican en grupos, según sean globales o de site, formando los grupos de replicación.

 

Cuando instalamos un site nuevo esta replicación necesita seguir unos pasos para poder inicializarse, serían:

1. La replicación comienza con una BulkCopy de ficheros, en realidad se copian las tablas que forman los grupos de replicación desde el servidor padre hasta la base de datos del servidor hijo, mediante una copia bcp de la base de datos.
2. Tras esta copia de ficheros puede comenzar la replicación, ya empleando elementos de SQL, de los cambios que se producen en la base de datos, para esto se emplea el puerto 4022 por defecto (ahora  ya es configurable en el site)

 

Tras esto ya está montada la replicación, ahora se tendrá un control de cambios en las bases de datos que alimentará los datos a replicar.

 

¿Y si la replicación falla?

Se tienen varias acciones automáticas en el site, si ninguna de estas funciona necesitaremos actuar para repararlo.

No podemos dejar mucho tiempo este componente sin atención, ya que tiene un tiempo límite de vida de los datos, si pasa este tiempo (5 días por defecto), se reiniciará todo el proceso, con un nuevo BulkCopy, moviendo un gran volumen de datos en la red.

 

Pero esta parte ya para otro post.

Step by step to solve client inventory issues

1. As a first step we may check if we have overlapping boundaries, which can be the source of the problem and save us review several logs.

http://blogs.technet.com/smsandmom/archive/2007/11/30/sms-2003-finding-overlapping-boundaries.aspx

2. Check if the client generates the inventory following the log inventoryagent.log 

3. Confirm if the client sends inventory to Management Point, you can see it on the log.

 Inventory: Successfully sent report. Destination:mp:MP_DdrEndpoint, ID: {0159F163-83C3-4B8B-8203-5245F4E2AECD}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted InventoryAgent 28/08/2015 12:20:53 1220 (0x04C4)

4. Check if the management point receives inventory (explained from step 6 onwards).

5. If the client sends the inventory, but it does not process the MP can review the XML generated by the client, for this follow these steps:

If you create a file named archive_reports.sms in the folder specified in the registry at HKLM \ Software \ Microsoft \ SMS \ Mobile Client \ Inventory \ Temp archive_reports.sms If this file exists at the time the file general inventory, .xml which is normally generated it will be temporarily stored in the inventory folder \ temp. The location is usually <DriveLetter>: \ SMS_CCM \ Inventory \ Temp or% SystemRoot% \ CCM \ Inventory \ Temp depending on whether the customer is or not a Management Point.

If all this works well on the client side, then we move on to the server side.

6. First we confirm that the client is communicating with the Management Point, the first step in the process of inventory files.

To do this, follow these steps:

On the client review the log ClientLocation.log, if we have miscommunication with the Management Point had to review the server, connecting to the Management Point that appears in this log and LocationServices.log.

7. The first thing is to check if the Management Point is working properly, for it can review the log Mpcontrol.log (located at:. \ Program files \ Microsoft Configuration Manager \ logs in SCCM) if it shows events 200 OK means that the Management Point this working properly in their communications.

8. After that check to see if the server receives client communication, for it as quickly is to review the IIS logs and filter by IP client (here it is useful tool TextAnalsysTool (add link to post).

9. If we see communication with 200 events then we turn to the Point Management logs, typically in the% Program Files% \ SMS_CCM \ Logs folder folder.

10. The next step is to review the MP_Hinv.log, in this we can see if the management point processes the client files.

11. If this works properly then we will go to the primary that has assigned the management point, and review the Dataldr.log to see how inventories are processed. Usually a very active file, so we’ll have to be quick in locating information or save a copy.

12. In some cases the Management Point does not work properly, an option (which should be the last), is to uninstall IIS (BITS useful for problems with the server), uninstall the role of Mangement Point, reboot, and reinstall IIS after that reinstall the Management Point, this will not affect other server roles (distribution manager will reconfigure the shares) but it can expose other problems in the server operating system that will make the situation complicated.

In sites with lots of activity it is advisable to force an inventory on the client, and in a few minutes reviewing / capture client and server logs, as these can be overwritten quickly and lose key to understanding the problem information.

13. To check whether the client can communicate with the Management Point can be run from a browser:

http: // <servername> /sms_mp/.sms_aut?mplist

http: // <servername> /sms_mp/.sms_aut?mpcert

14. If we have problems with BITS IIS will see events like the following in the IIS log:

2008-10-06 18:11:51 W3SVC1 10.175.8.15 BITS_POST

/ CCM_Incoming / {6B98ED15-004F-413B-AF43-ECA6D6FB3BF2}

(Bits_error: {263BF497-9FE7-4220-9C8C-D42F111454E5}, 403,0×80070005) 80 – 10.164.2.52

Microsoft + BITS / 6.7 403 0 0

We may need to reinstall the Management Point following the next steps:

1) In the ConfigMgr admin console, uninstall the Management Point (MP)

>> in ConfigMgr admin console, go to the site system, deselect the MP role, watch MPSetup.log

2) Uninstall IIS

>> go to add remove programs, then add remove windows components, deselect Internet Information Services (IIS), next, next… let it complete

http://www.iis.net/learn/install/installing-iis-85/installing-iis-85-on-windows-server-2012-r2

3) Reboot the server

4) Reinstall IIS, making sure the components needed by ConfigMgr/SCCM 2007 are also installed (BITS, WebDAV, etc)

5) Reinstall the Management Point (MP)

>> in ConfigMgr admin console, go to the site system, select the MP role, watch MPSetup.log

I hope that this be informational for you.

Pasos a seguir en caso de problemas de inventario en el cliente

Como primer paso podemos revisar si tenemos overlapping boundaries, que puede ser este el origen del problema y nos ahorrara revisar varios logs.

http://blogs.technet.com/smsandmom/archive/2007/11/30/sms-2003-finding-overlapping-boundaries.aspx

1.   Revisar si el cliente realiza el inventario en inventoryagent.log (hablar sobre el verbose log y diferencias entre la informacion generada)

2. Confirmar si el cliente envía el inventario al Management Poin

Inventory: Successfully sent report. Destination:mp:MP_DdrEndpoint, ID: {0159F163-83C3-4B8B-8203-5245F4E2AECD}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted InventoryAgent 28/08/2015 12:20:53 1220 (0x04C4)

3. Confirmar si el Management Point recibe el inventario (ampliado del paso  6 en adelante).

4. Si el cliente envia el inventario, pero el MP no lo procesa podemos revisar el xml que genera el cliente, para esto seguir estos pasos:

Si creamos un fichero llamado archive_reports.sms en la carpeta especificada en el Registro en HKLM\Software\Microsoft\SMS\Mobile Client\Inventory\Temp Si este fichero archive_reports.sms existe en el momento de general el fichero de inventario, el .xml que se genera normalmente de forma temporal se almacenará en la carpeta inventory\temp. La localización suele ser  <DriveLetter>:\SMS_CCM\Inventory\Temp o %SystemRoot%\CCM\Inventory\Temp dependiendo de si el cliente es o no un Management Point.

Si todo esto funciona bien en la parte cliente, entonces deberemos movernos a la parte servidora.

5. Primero deberemos confirmar que el cliente está comunicando con el Management Point, primero paso en el proceso de los ficheros de inventario.

Para ello seguiremos estos pasos:

6. En el cliente revisar el log ClientLocation.log, si no tenemos errores de comunicacion con el Management Point pasamos a revisar el server, conectandonos al Management Point que aparece en este log y en LocationServices.log.

7. Lo primero es revisar si el Management Point funciona correctamente, para ello podemos revisar el log  mpcontrol.log (localizado en : \program files\Microsoft Configuration Manager\logs in SCCM.) si muestra eventos 200 OK significa que el Management Point esta funcionando correctamente en sus comunicaciones.

8. Tras esto revisamos si el servidor recibe comunicación del cliente, para ello lo mas rápido es revisar los logs de IIS y filtrar por la IP del cliente (aqui es útil la herramienta TextAnalsysTool (añadir link al post).

9. Si el vemos comunicacion con eventos 200 entonces pasamos a los logs del Management Point, normalmente en la carpeta %ProgramFiles%\SMS_CCM\Logs folder.

10. El siguiente paso es revisar el MP_Hinv.log, en este podremos ver si el management point procesa los ficheros del cliente.

11. Si esto funciona correctamente entonces iremos al primario que tiene ese management point asignado, y revisaremos el dataldr.log para ver cómo se procesan los inventarios. Suele ser un fichero muy activo, con lo que tendremos que ser rápidos en la localización de la información o en salvar una copia.

12. En algunos casos el Management Point no funciona correctamente, una opción (que debe ser la última), es desinstalar IIS (útil para problemas con BITS en el server), desinstalar el role de Mangement Point, reiniciar la máquina, reinstalar IIS y tras esto reinstalar el Management Point, esto no afectará a otros roles del server (distribution manager volverá a configurar los shares) pero puede sacar a la luz otros problemas en el sistema operativo del servidor que hagan que se complique la situación.

En sites con mucha actividad lo recomendable es forzar un inventario en el cliente, y en pocos minutos revisar/capturar los logs de cliente y servidor, ya que estos se pueden sobrescribir con rapidez y perder información clave para entender el problema.

13. Para comprobar si el cliente puede comunicar con el Management Point podemos ejecutar desde un navegador:

http://<servername>/sms_mp/.sms_aut?mplist

http://<servername>/sms_mp/.sms_aut?mpcert

14. Si tenemos problemas con BITS en IIS veremos eventos como el siguiente en el IIS log:

2008-10-06 18:11:51 W3SVC1 10.175.8.15 BITS_POST

/CCM_Incoming/{6B98ED15-004F-413B-AF43-ECA6D6FB3BF2}

(bits_error:{263BF497-9FE7-4220-9C8C-D42F111454E5},403,0×80070005) 80 – 10.164.2.52

Microsoft+BITS/6.7 403 0 0

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

Reinstalar el role del Management Point siguiendo estos pasos:

1) En la consola de administración de ConfigMgr, desinstalar el role de Management Point (MP)

Poder seguir el proceso en el log MPSetup.log

 

2) Desinstalar el role de IIS en el servidor:

>> Desde add remove programs, seleccionar el  add remove windows components, quitar la selección sobre Internet Information Services (IIS), siguiente, siguiente… Dejarlo completar

http://www.iis.net/learn/install/installing-iis-85/installing-iis-85-on-windows-server-2012-r2

 

3) Reiniciar la maquina con el role de Mangement Point Server.

4) Reinstalar IIS, asegurandonos de que añadimos todos los componentes de IIS que son necesarios para  ConfigMgr/SCCM 2007 (BITS, WebDAV, etc)

5) Reinstalar el role de Management Point (MP) desde la consola.

Espero que esta información os resulte de utilidad.