Social Icons

twitter facebook google plus linkedin

Featured Posts

miércoles, 18 de enero de 2017

Enviar datos a Azure Mobile Apps usando jQuery

Hola Mundo:

Este artículo es un tanto distinto a los que siempre se publican. Esta vez es sobre desarrollo, pero
consumiendo servicios publicados en Microsoft Azure.

Azure Mobile Apps es un servicio de Microsoft Azure que permite levantar, sin mayor esfuerzo, un backend para aplicaciones móviles. Este backend puede estar construido con ASP.NET o Node.js.
De cualquier manera, provee las herramientas para generar una REST API lista para ser consumida desde las aplicaciones cliente.

Me refiero a aplicaciones cliente y no móviles, porque estos servicios pueden ser consumidos desde cualquier lugar. Incluso desde un sistema web usando Javascript.

En este caso puntual, compartiré una ayuda de memoria para enviar datos usando jQuery usando el método AJAX:
$.ajax({
 type: "POST",
 contentType: "application/json; charset=UTF-8",
 url: "https://xxxxxxx.azurewebsites.net/tables/xxxxxx",
 headers: {'ZUMO-API-VERSION': '2.0.0', 'Content-Type': 'application/json'},
 data: JSON.stringify({
  "Campo1": "Valor1",
    "Campo2": "Valor2"
 }),
 dataType: "json",
 accept:  "json",
 success: function(datos){
   console.log(datos)
   alert('Datos reportados correctamente')
 },
 error: function(jqXHR, estado, error){
   console.log(estado)
   console.log(error)
 },
 complete: function(jqXHR, estado){
   console.log(estado)
 },
 timeout: 1000000000
});

Lo relevante:

  • El type es POST. No olvidar que estamos enviando datos al servidor. Si tienes duda sobre esto, revisa este link: http://www.restapitutorial.com/lessons/httpmethods.html
  • contentType debe ser "application/json; charset=UTF-8". El servidor recibe datos en formato JSON. De otra forma, arrojará error 500.
  • La url es la dirección web del servicio. Esta es la forma más estándar si es que no han creado una personalizada.
  • La cabecera de la petición se indica en headers. Siempre debe estar incluido 'ZUMO-API-VERSION': '2.0.0' y  'Content-Type': 'application/json'. En el caso que alguno falte, la consola indicará que hace falta una de las dos y arrojará un error 500 o 400.
  • En data se indican los datos que se enviarán. El método stringify del objeto JSON es el encargado de hacer que los datos que estamos enviando sigan el formato de JSON.  Recuerden que en contentType y en la cabecera se indica que estamos enviando datos en formato JSON. Si esto no está, recibirán un error 400.
  • El atributo accept le indica al servidor el formato en el que se requiere la respuesta.
  • El atributo dataType es usado por jQuery para "formatear" la respuesta antes de dejarla disponible para el trabajo con ella.
  • Success indica la función que se ejecutará cuando los datos se reporten correctamente.
  • Error indica la función que se ejecutará cuando se produzca un error en el reporte de datos.
  • Complete indica la función que se ejecutará luego de la ejecución de lo indicado en Success o Error.
  • Timeout indica el tiempo total de espera, en milisegundos, antes de cancelar la operación. Previene una ejecución casi infinita de la solicitud.
Nada más quería estar a la moda y jugar un rato con Javascript y Azure.

Espero que les sea de su total utilidad.

miércoles, 4 de enero de 2017

WSUS no sincroniza con SCCM. Error 503

Primer artículo del año. 

Este año se abre con una problemática muy habitual de WSUS y SCCM y guarda relación cuando el
rol de Software Update Point de SCCM no logra conectarse con el servicio de WSUS para gatillar la la actualización del catálogo de actualizaciones para los productos Microsoft seleccionados.

El servicio de WSUS provee una capa de servicios web que otros componentes, como SCCM, consumen para la interoperación.

El signo observado es el error de SCCM al sincronizar con el servicio. Al revisar el log SMS_WSUS_SYNC_MANAGER vamos a encontrar el siguiente mensaje:

Message ID: 6703 WSUS Synchronization failed. Message: The request failed with HTTP status 503: Service Unavailable. Source: Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer.

Básicamente, lo que se indica es que al intentar acceder al servicio web, éste le responde con un error 503. 
Si hacen el ejercicio de entrar por el navegador a la URL del servicio, el resultado será el mismo.

Al abrir la consola de IIS y revisar los App Pool encontrarán que WsusPool se encontrará detenido:
fuente: Blogs Technet

Ahí está el problema. El App Pool se encuentra detenido. Tienes dos opciones: Inciarlo de forma manual y esperar a que nuevamente se caiga, o bien, solucionar el problema.

Me inclino por la segunda opción. El problema está en que el App Pool cuenta con memoria asignada insuficiente para atender las peticiones de los clientes. Cuando hay muchos clientes haciendo uso del servicio, se va a utilizar toda la memoria y el servicio se detendrá.

Para corregir el problema entrar a las opciones avanzadas y buscar el elemento Private Memory Limit (KB) y asignarle un valor mayor. Quizá unos 4 ó 5 GB estará bien.
Fuente: Blogs Technet

Advertencia: Al aumentar la memoria asignada, el uso de recursos del servidor aumentará y provocará una carga mayor sobre el mismo. Al acceder muchos clientes al mismo servidor para la descarga de actualizaciones, es altamente probable que la red sufra un alto impacto. Si esto ocurre, sugiero revisar la arquitectura de distribución de paquetes.

Una vez realizado el cambio, iniciar el App Pool y el servicio funcionará normalmente.

Saludos!

martes, 8 de noviembre de 2016

Consola de SCOM se cierra de forma inesperada

Hola Mundo:

El día de ayer atendí un caso de soporte en el que la consola se SCOM 2012 R2 se cerraba de forma
inesperada.
Según el visor de eventos, el mensaje de error reportado es:

Faulting application name: Microsoft.EnterpriseManagement.Monitoring.Console.exe, version: 7.1.10226.1090, time stamp: 0x55ba7214
Faulting module name: ntdll.dll, version: 6.1.7601.23543, time stamp: 0x57d2fde1
Exception code: 0xc0000374
Fault offset: 0x00000000000bf262
Faulting process id: 0x1038
Faulting application start time: 0x01d2393cc1f5ba30
Faulting application path: E:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Haciendo una investigación en mi buscador favorito, encuentro que otros usuarios han reportado el mismo comportamiento luego de la instalación de una actualización de octubre del 2016.
Una rápida solución consiste en la desinstalación de la actualización KB3185331.

Afortunadamente, Microsoft ya se hizo cargo del problema y liberó una actualización:
https://support.microsoft.com/en-us/kb/3200006

Solución: Instalar la actualización especificada en el link y reiniciar el servidor.

Más referencia sobre el problema:

Éxito!


viernes, 4 de noviembre de 2016

Ejecutar acciones en clientes SCCM de forma remota

Hola Mundo:
En implementaciones de SCCM para la administración de estaciones de trabajo es necesario realizar
refresco de políticas de algunas máquinas cliente antes del tiempo agendado de refresco.
Me explico. Por defecto, todas las máquinas conversan con el servidor de administración (MP) una vez cada 60 minutos. Estos minutos se empiezan a contar cuando se instala el agente, por lo que no todos los agentes sincronizan al mismo tiempo.
A través de la máquina local del cliente se puede forzar la ejecución del refresco de políticas de máquina, que alteraría el normal tiempo de refresco. 
Para efectos de pruebas y distribución de algún paquete es necesario hacerlo, pero supone un problema darle las indicaciones al usuario para que el lleve a cabo la acción, o bien, intentar conectarse a su máquina e interrumpirlo en sus labores, también es un problema.

Afortunadamente, SCCM y sus agentes funcionan sobre WMI para la ejecución de sus procesos y recolección de información. Teniendo esto asumido, ya podemos decir que se pueden ejecutar procesos de WMI de forma remota.

Cada una de las acciones del agente de SCCM está identificado a través de un identificador. Los más comunes son:
  • Hardware Inventory: {00000000-0000-0000-0000-000000000001}
  • Software Inventory: {00000000-0000-0000-0000-000000000002}
  • Machine policy retrieval and evaluation cycle: {00000000-0000-0000-0000-000000000021}
El cmdlet Invoke-WmiMethod nos apoyará en esta operación. 

Por ejemplo, si se necesitara ejecutar la acción de refresco de políticas de máquina la linea para ejecutar en Powershell sería así:


 Invoke-WmiMethod -ComputerName NOMBRE_DEL_CLIENTE -Namespace root\CCM -Class SMS_Client -Name TriggerSchedule -ArgumentList "{00000000-0000-0000-0000-000000000021}"

Es importante que la sesión de Powershell debe ser con privilegios de administración local de la máquina cliente.
¿Ven? ya se pueden ahorrar problemas y optimizar el trabajo.

Saludos!