Los administradores de UNIX/Linux se han beneficiado desde hace tiempo de un entorno de programación robusto y capaz que se encuentra en el propio sistema operativo. La creación de scripts de shell ha permitido al administrador la automatización a gran escala de los procesos del sistema y sus programas, a la vez que ha asegurado la continuidad de los procedimientos, una recuperación fiable en caso de desastre y facilitado la administración remota. Los administradores Microsoft han tenido que arreglárselas con los ficheros de proceso por lotes (batch), que en comparación no son más que restos primitivos de los días antiguos del DOS de Microsoft. Aunque sin duda hay algunos autores que han creado soluciones muy brillantes en ese entorno, las capacidades de los script de shell de UNIX/Linux están a años luz de las de los ficheros de proceso por lotes de DOS. Las metodologias altamente propietarias de la administración basada en GUI de los servidores Windows implican que son incapaces de compartir los más rutinarios guiones de automatización y procedimientos de la forma que lo hacen todas las versiones de UNIX y Linux. Despues de todo, ¿cómo pueden escribirse las puslsaciones del ratón en un entorno GUI en un fichero de texto fácil de leer y editar y que sea portable mediante disquete o correo electronico?. No se puede.
Windows XP no es compatible con POSIX, lo que significa que no puede alcanzar una similitud básica con el interprete de comandos de UNIX/Linux. El subsistema POSIX que habia disponible para Windows NT y 2000 se eliminó de Windows XP y ahora sólo está disponible con un coste adicional en licencias.
Microsoft ha elegido VBScript, una variante de JavaScript de Netscape Corporation, como medio de alcanzar aproximadamente las mismas capacidades que los scripts de UNIX/Linux. Sin embargo, VBScript ha demostrado ser una fuente de grandes preocupaciones de seguridad, puesto que su actitud inherente de seguridad es la "permisividad", que significa que la mayoría o todas las rutinas se consideran "confiables" a menos que se configure lo contrario. Esto es justo lo contrario del paradigma de seguridad en UNIX/Linux, en el cual la actitud por defecto es "denegación" hasta que se reconfigure de forma adecuada. El resultado del débil modelo de seguridad de Microsoft VBScript es la aparente facilidad con la cual el código malévolo puede dañar los recursos del sistema operativo de Microsoft, como se puede ver en la letanía de asaltos de virus en todo el mundo.
Casi cualquier rutina de administración del sistema hecha a medida desarrollada para operar una máquina UNIX puede adaptarse rápidamente con cambios menores y ejecutarse en una máquina Linux. Estas rutinas no funcionarán en la plataforma Microsoft. Por tanto, el tener una mezcla de entornos de sistemas operativos sigue necesitando que los administradores creen un conjunto de "scripts" universales y un segundo conjunto de ficheros de proceso por lotes DOS "sólo-Microsoft" y/o procedimientos basados en VBScript. Como paradigma de la industria o en lo referente a su eficiencia en este rol, VBScript no ha dado la talla y su adopción ha sido muy baja.
Para los administradores listos de tiendas TI mixtas, el software Open Source ha ayudado enormemente a tender un puente sobre el abismo. Quizás el lenguaje multiplataforma más popular y conveniente de administración del sistema es Perl, el "Lenguaje Práctico de Extracción e Informe", ideado por Larry Wall y ofrecido sin coste. Perl mno es un recién llegado, ha estado disponible desde hace años en los SO UNIX y Linux, y se ha portado a la plataforma Windows. De hecho, Microsoft ha contribuido en gran medida a portar de forma activa Perl a Windows. Sería dificil encontrar un lenguaje de computación tan tan extensible, flexible y seguro como Perl. Inevitablemente, la popularidad de Perl se ha filtrado al mundo Windows, haciendo posible la administración de plataformas cruzadas basandose en las contribuciones durante años de muchas personas al Open Source. Comparado con Perl, VBScript se vé como una opción pobre.