Convertir entero en IP con PowerShell

Una forma muy eficiente de almacenar direcciones IPv4 en una base de datos es almacenarlas como enteros de 32 bits. El procedimiento es bastante sencillo y hay herramientas y librerías para muchos lenguajes de programación.
El único inconveniente de esta forma de almacenamiento es que a simple vista es muy dificil saber a que dirección IP corresponde un entero cualquiera.

Por ejemplo, -1062731495 equivale a 192.168.1.25 y 624686204 a 37.59.244.124. Imposible saberlo, ¿no?

Últimamente me encuentro haciendo muchas consultas en una base de datos que almacena las IP de esta forma, por lo que decidí hacerme la vida mas fácil creando una pequeña funcion en PowerShell que convierta este formato críptico en el formato al que estoy acostumbrado (XXX.XXX.XXX.XXX).

Convert-IntToIPv4

Puedes descargar el archivo PS1 desde Convert-IntToIPv4.

Referencia

¡Cuidado con los parches de Office 2013 en SCCM 2012 R2!

Hoy tuve un pequeño momento “WTF Microsoft?!” cuando me puse a descargar los parches de Office 2013 en SCCM 2012 R2.

Resulta que no importa la configuración de idiomas que tengas configurada en tu SUP o en el WSUS. El SCCM SIEMPRE va a descargar TODOS los idiomas de los parches de Office 2013. Lo mejor de todo es que no es un bug, es una decisión de diseño (¿Eh?).

¿Qué significa esto? Que por ejemplo, para el SP1 de Office 2013, en vez de 650 MB se van a descargar 650 MB * Número de idiomas soportados (después de 20 paré de contar). Esto se convierte en una pesadilla a la hora de transferir los paquetes de despliegue a los DP. No es lo mismo pasar 650 MB que pasar 10 GB por un enlace de 2 MB 🙂

Así que ya sabéis, mucho cuidado al descargar estos parches en vuestro entorno.

Referencia

Reparar tareas programadas corruptas en Windows 7

Hace unos días actualicé mi portátil de casa de Windows 7 a Windows 10 para probarlo y enterarme un poco de qué estaba hablando todo el mundo. La verdad es que fue una experiencia bastante buena, la instalación se hizo sin problemas y todo corría bastante bien en mi “abuelo” de hace cuatro años.

Desafortunadamente, tuve varios problemas de compatibilidad con algunos programas y tuve que volver a Windows 7. Otra experiencia bastante buena, todo funcionaba sin problemas o eso pensaba yo.

Hasta que llegó el domingo y el equipo no me pidio hacer el backup semanal. Mm… raro, raro.

Voy a ver las tareas programadas y me aparece el siguiente error:

error tareas programadas

Le doy a Aceptar y el mismo error me aparece para las siguientes tareas:

  • ActivateWindowsSearch
  • AutoWake
  • BackgroundConfigSurveyor
  • ConfigureInternetTimeService
  • DispatchRecoveryTasks
  • ehDRMInit
  • GadgetManager
  • HotStart
  • InstallPlayReady
  • IpAddressConflict1
  • mcupdate
  • mcupdate_scheduled
  • MediaCenterRecoveryTask
  • ObjectStoreRecoveryTask
  • OCURActivate
  • OCURDiscovery
  • PBDADiscovery
  • PBDADiscoveryW1
  • PBDADiscoveryW2
  • PvrRecoveryTask
  • PvrScheduleTask
  • RacTask
  • RecordingRestart
  • RegisterSearch
  • ReindexSearchRoot
  • SessionAgent
  • SystemDataProviders
  • UpdateRecordPath
  • Windows Backup Monitor
  • WindowsParentalControls

Fuck… Algo está mal.

Buscando en la web me di cuenta de que muchas personas tenían este mismo problema y que lo solían resolver restaurando desde un punto de restauración. El problema es que los míos ya se habían borrado.

Apoyándome en este KB logré solucionar el problema.

Al parecer, cuando Windows 7 pasa a Windows 10 o viceversa (no se exáctamente cuándo), se cambian los GUID de las tareas programadas, junto con sus archivos XML correspondientes. Y cuando se hace la marcha atrás estos cambios no se revierten, quedando todas las referencias de las tareas programadas mal.

Exportando el registro de mi equipo y comparándolo con el del trabajo se ve claramente el problema:

Casa:

error tareas programadas casa

Trabajo:

error tareas programadas trabajo

El hash sigue siendo el mismo, pero el trigger cambia. Esto no tiene mucho sentido si sigue siendo la misma tarea, ¿no?.

Los XML correspondientes también eran ligeramente diferentes (un backslash de más):

error tareas programadas xml

Para resolver todo hice lo siguiente:

OJO, NO SIGAS ESTOS PASOS A MENOS QUE SEPAS BIEN LO QUE ESTÁS HACIENDO.

  1. Abrir una sesión de consola como SYSTEM usando psexec. Para esto hay que ejecutar psexec -i -s -d cmd. Esto es porque la mayoría de las cosas que hay que hacer están restringidas a este usuario.
  2. Exportar los archivos XML por si acaso. xcopy /e c:\windows\system32\tasks\ c:\backuptasks
  3. Desde la ventana de cmd de SYSTEM abrir regedit y exportar el registro por si acaso. La clave a exportar es HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\
  4. Hacer una copia del registro exportado que es el que vamos a editar.
  5. En el registro exportado reemplazar los valores de Path, Hash, Triggers y DynamicInfo por los valores por defecto. Estos valores los puedes ver en este archivo. Hay que tener mucho cuidado de no cambiar el GUID.
  6. Parar el servicio Programador de Tareas. net stop schedule
  7. Reemplazar los XML por los originales. Los originales los puedes descargar desde aquí
  8. Importar el archivo de registro editado.
  9. Iniciar el servicio Programador de Tareas.
  10. Reiniciar el equipo.
    • Si algo sale mal y las tareas siguen apareciendo como corruptas hay que hacer lo siguiente:

      1. Abrir una consola como SYSTEM.
      2. Parar el servicio Programador de Tareas.
      3. Importar el registro de backup
      4. Restaurar los XML a los que se les hizo backup
      5. Iniviar el servicio Programador de Tareas
      6. Reiniciar

      Como lo dije arriba, esto es muy peligroso porque estás tocando el registro de Windows como SYSTEM (MAL!) y si no tienes cuidado te puedes cargar todo el sistema operativo.

      Si tienes dudas con algo de esto es mejor que reinstales Windows.

Instalar cliente SCCM 2012 R2 en sedes remotas o con poco ancho de banda

Uno de los muchos retos de trabajar con empresas grandes es que siempre tienen sedes en la Cochinchina, con enlaces de 256 kbps (tirando para arriba), a las que hay que desplegarle software. Normalmente, estas sedes remotas no tienen suficientes equipos como para “merecer” un servidor propio, pero si suficientes como para saturar los enlaces al intentar desplegar CUALQUIER COSA.

Un ejemplo de estos despligues es el cliente de SCCM. Este cliente, junto con sus paquetes de soporte sube hasta aproximadamente 100 MB. Si intentamos desplegar esto a una sede con 10 clientes y un ancho de banda de 256 kbps tardaríamos unas 8+ horas, sin tomar en cuenta el overhead de las comunicaciones y saturando completamente el enlace. Esto último no es aceptable, ya que seguramente los usuarios necesiten trabajar con el correo, ERP, ficheros, etc.

Pudiesemos dejar los equipos encendidos y lanzar el despliegue un fin de semana, pero a mi, particularmente, me gusta más dormir 🙂

Lo que podemos hacer en este caso es transferir la carpeta de instalación del cliente a un solo equipo remoto, y ejecutar el resto de instalaciones desde una carpeta compartida en ese equipo, utilizando PSExec.

Los pasos serían mas o menos los siguientes:

  1. Copiar la carpeta Client desde el servidor de SCCM al equipo destino. Esta carpeta se suele encontrar en C:\Program Files\Microsoft Configuration Manager\Client.
  2. Compartir la carpeta Client. Tenemos que asegurarnos de darle permisos de lectura al usuario que va a realizar la instalación.
  3. Lanzar la instalación en los equipos remotos usando PSExec. El comando sería: psexec \\pcremoto ccmsetup.exe /source:\\equipoConCarpetaCompartida\carpetaCompartida SMSMP=miServidorMPdeSCCM. Es MUY importante el orden de los parámetros (estuve casi un año medio buscando por qué los parametros no me funcionaban hasta que di con este blog). Ya lo se… RTFM.

Una vez lanzada la instalación, los clientes van a extraer los ejecutables necesarios desde el equipo local con la carpeta compartida, en vez de descargar todo desde el Distribution Point mas cercano.

Federación Lync 2010 con Skype/Yahoo/AOL

Por algún motivo que desconozco, está información me costó bastante encontrarla.

La copio aquí para futura referencia y para el resto de la gente. A ver si cambiando las keywords es más fácil de encontrar la próxima vez.

Si quieres establecer federación de Lync 2010 (on-premises) con cuentas de mensajería pública como Skype/Yahoo/AOL debes dar de alta tu entorno de Lync en https://pic.lync.com. Para esto vas a necesitar tus datos del acuerdo con Microsoft, los datos de tu Access Edge y los dominios SIP que vas a federar.

Más información en https://technet.microsoft.com/library/dn440173.aspx

Lync falla al compartir pantalla/presentación

Al intentar compartir la pantalla desde Lync 2013 nos estaba apareciendo este error a un par de nosotros: “An error occurred during the screen presentation”.

Nos pareció bastante raro ya que anteriormente esto había funcionado sin problemas. Así que intentamos de nuevo y funcionaba. Intentamos una vez más, fallaba otra vez. Intentamos una última vez y funcionaba.

Mmm… esta intermitencia era un poco rara. Así que lanzamos el Wireshark y empezamos a ver que pasaba. Y como siempre, este nos dió la respuesta.

Nuestros equipos de trabajo son portátiles y casi siempre estamos conectados a la WiFi corporativa y a la red cableada al mismo tiempo. Lo que estaba pasando en este caso era que algunas conexiones de Lync se estaban estableciendo por un enlace y la otras por el otro y por lo visto esto no le gusta al Lync y las presentaciones fallaban. Tan pronto como desactivamos uno de los enlaces las presentaciones empezaron a funcionar siempre.

Probablemente tengamos un detalle de configuración en alguna parte y tenemos que seguir revisando. Mientras tanto, tenemos este workaround.

Así que ya sabéis, incluid este paso dentro de vuestro troubleshooting de Lync 🙂

Error al iniciar sesión en SQL Server Management Studio

Esto es tan tonto que casi me da penita ponerlo aquí…

Después de agregar un grupo de administradores como sysadmin a una instancia de SQL Server 2008 R2 intentaba iniciar sesión en SSMS, y este me recibía con “Login failed for user ‘MiDominio\MiUsuario'”.

¿Eh?

Reviso los logs de SQL y veo “Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors.”

Nuevamente, ¿Eh?

Busco en San Google y veo que la razón era muy sencilla, había que lanzar el SSMS como Administrator (clic derecho -> Ejecutar como Administrador) porque el UAC no estaba pasando todas las pertenencias a grupos.

Todos los días se aprende algo nuevo.

Referencia