La clave de registro es la siguiente:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Drive
En tileinfo, quitar exactamente “System.PercentFull;” manteniendo el * que hay al principio.
Saludos.
La clave de registro es la siguiente:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Drive
En tileinfo, quitar exactamente “System.PercentFull;” manteniendo el * que hay al principio.
Saludos.
Hola.
Hoy se me ha planteado la necesidad de salvar y luego volver a importar la configuración de unas cuantas tarjetas de red y en vez de hacerlo a mano, he buscado el comando y aquí está. Como siempre, pararse a afilar el hacha es un tiempo bien dedicado.
El comando para exportar la configuración es:
netsh -c interface dump > archivo.txt
El comando para importar la configuración exportada es:
netsh -f archivo.txt
Saludos.
La descripción de funcionamiento de BranchCache en modo distribuido sería la siguiente.
Escenario:
1. Servidor Windows Server 2008 R2 con rol de servidor de ficheros, carpeta compartida y en esta última, tenemos marcada la opción de BranchCache o si se trata de http, debemos tener publicado la carpeta donde se almacena la web.
2. Equipo cliente A con Branchacache activado vía gpo o en gpedit local y reglas de firewall en modo permitido.
3. Equipo cliente A, tiene configurado mediante gpo o gpedit local, el tiempo de corte por el cual, si el servidor funciona más lento del tiempo establecido, el archivo se cacheará y será ofrecido a otros pcs de la Lan.
3. Equipo cliente B igual a equipo cliente A.
Funcionamiento:
1. El equipo cliente A, solicita a servidor los identificadores del archivo que necesita. Esta solicitud puede ser Http, bits o smb, mediante también https o ipsec.
2. El cliente A, busca en local y en su LAN mediante WS-Discovery, en este primer uso, el archivo nunca ha sido descargado.
3. El cliente A, descarga el archivo desde el servidor.
4. El cliente B, solicita a servidor los identificadores del archivo que necesita. Esta solicitud puede ser Http, bits o smb mediante también https o ipsec.
5. El cliente B, busca en local y en su LAN mediante WS-Discovery. En este segundo uso, el archivo previamente ha sido descargado por el Cliente A.
6. El cliente B, comprueba que la comunicación con el servidor es mayor y por tanto más lenta en milisegundos que lo establecido en la gpo o gpedit local.
6. El cliente A, ofrece a cliente B el archivo.
Hasta aquí, la descripción de como funciona el servicio.
Configuraciones
Servidor:
1. Instalar característica File server y Branchcache.
2. Directiva de equipo local o gpo – Equipo – Plantillas administrativas – Red – Servidor lanman –Publicación de hash para BranchCache – Habilitado y elegir una de las opciones, yo prefiero – Permitir publicación de hash para shares con branchcache habilitado.
SMB
1. Activar rol de servidor de ficheros.
2.Compartir una carpeta
3. Propiedades – compartido – avanzado – cacheado – marcar “Enable BranchCache”.
SMB en clúster
Si vais a utilizar smb en clúster, tenéis que lanzar en todos los nodos el siguiente comando: netsh branchcache set key passphrase=“frase secreta”, debéis repetir la misma frase en todos los nodos.
HTTP
1. Lanzar CMD como adminsitrador
2. publish-bcwebcontent (ruta de la web: ej.c:\inetpub\wwwroot )
Equipos cliente:
1. La gpo o gpedit local en los equipos cliente deben tener configurado:
2. Configuración de Firewall:
Tras esta configuración, podemos lanzar en un cmd como administrador y consultar si todo está ok, gracias la comando netsh branchcache show status all, donde también podéis ver la cantidad de información cacheada en el equipo.
Probar Branchcache
Para probar la configuración y funcionamiento de BranchCache, solo tendrías que:
1. Instalar un emulador de linea, por ejemplo:
NetworkEmulatorToolkit_x32
NetworkEmulatorToolkit_x64
2. Instalar este emulador en el servidor , configurar y en los filtros configurar una latencia mayor que la configurada en la gpo de los equipos cliente (Equipos cliente punto 1.4).
3. Copiar a local en Equipo A o descargar de una web un archivo y observar el tiempo que tarda en finalizar el proceso.
4. Realizar el mismo proceso en Equipo B. El tiempo ha e ser considerablemente menor porque Equipo A ha de ser quien entrega los datos, contando con una latencia mínima en Lan.
Hola.
Este es el primero de varios artículos donde pretendo hablar de BranchCaché en un claro ejemplo de uso, una migración de datos actualmente descentralizados a una cloud privada centralizada. Este primer artículo nos pondrá en situación y describirá las partes importantes ante la toma de decisiones en la fase de diseño.
BranchCaché en todo proyecto de centralización de datos en Cloud 1/3
Dos proyectos combinados en los que estoy metido, tienen como fin el diseño y ejecución de una migración de file servers localizados en más de mil “sites” a una cloud privada. Se pretende consolidar y explotar al máximo las ventajas propias de la centralización de datos. Esto conlleva la combinación de un proyecto de migración y otro en paralelo, donde diseñamos y creamos un clúster contando con las mejoras ofrecidas por los roles de File Server y Storage de WS2012. Además de otros que no vienen tan a cuento pero que también son imprescindibles, como la creación de una CA Corporate.
Pues bien, centrándonos en el primero de ellos y contrariamente a lo que se puede pensar, el éxito de ese proyecto, no se basa tanto en los extremadamente importantes procedimientos de migración o en el estudio y mejora de anchos de banda, sino que la parte imprescindible en este proyecto se llama aceleración y en nuestro caso, la encontraemos gracias a BranchCache. Podemos resumirlo en que cualquier ancho de banda posible actualmente, no sustituirá nunca al antiguo servidor situado en la lan y dado esto, se asume cierta lentitud en algunos momentos versus ahorro y seguridad de datos, pero, para minimizar, incluso evitar esta lentitud, pongamos un servidor que haga funciones de hosted ya que además, este puede caer, ser formateado o reemplazado rápidamente sin correr grandes riesgos.
Dicho esto, es importante conocer el rol (http://technet.microsoft.com/en-us/network/dd425028.aspx) y su encaje en el escenario.
Bases:
1. Podremos utilizar Windows Server 2008 r2 o Ws2012 en los servidores pero Windows 7 en equipos cliente.
2. Podríamos utilizar sites con Caché distribuida o Hosted Caché (recordamos que el fin del proyecto es consolidar y por tanto, apagar la mayor cantidad de servidores de site posibles).
3. Anchos de banda limitados y no mejorables en multitud de sites.
4. Diferentes subredes en ciertas redes (Branchcaché distributed, solo cachea información entre equipos en la misma subred).
5. Hosted Caché en Ws2008R2 ya nos permite pre cachear información en el servidor previo a su puesta en producción.
6. Windows 7, al contrario de Windows 8, no detecta automáticamente al servidor hosted de la sede, por lo que se prone ligar una gpo con el servidor por cada site.
7. Hosted Caché se basa en la seguridad ofrecida por certificados de servidor, por lo que tenemos que contar con una CA Corporate.
8. Los servidores hosted ws2012 y Ws2008R2 pueden ser detectados automáticamente por futuros w8, por lo que se podría habilitar esta opción aun no siendo explotada actualmente.
9. Ante oscilaciones en las velocidades de conexión, se pretende cachear la mayor cantidad de información, independientemente al retardo con el servidor central.
Tras conocer todo esto, iremos desgranando como funciona y la puesta en marcha de BranchCaché distribuido y sobre todo Hosted, que es el que nos costará un poco más de montar.
Saludos.
Hola.
En su día ya traté por aquí, el hecho de que no todas los componentes vengan almacenados en el propio sistema operativo a la espera de ser activados; eso ocurre en W8, WS2012 y WS2012R2.
El ejemplo es claro, prácticamente lo primero que encontramos cuando queremos instalar algún rol es la necesidad de contar con .net framework y este, se descarga online, algo que normalmente, nuestros servidores no pueden realizar.
Para remediar esto de forma profesional en un entorno al menos mediano, lo suyo es crear una directiva que nos ayude, para ello, basta con seguir los siguientes:
1.Crear una directiva e ir a la ruta:
Computer configuration\administrative Templates\system\Specify settings fo optional component installation and component repair
2.Activar la opción y en “Alternate source file path” podemos:
2.1 Simplemente utilizar la ruta de un share, donde habremos guardado los archivos del iso; ejemplo: \\nas\share
2.2 Utilizar un share donde hemos guardado el archivo wim e indicarlo todo, ejemplo: wim:\\nas\share\install.wim:3.
En mi caso he usado la opción 1 ya que la 2 viene perfectamente detallada en la ayuda:
Además, también podéis personalizar la opción contando con las opciones “never attempt to download payload from windows update” o “contact Windows Update directly to download repair content…”, las cuales están perfectamente explicadas en la parte de la ayuda de la propia opción.
Saludos.
Hola.
Un olvidado a la hora de aumentar la seguridad de nuestra red es el servicio de blocklist de nuestro DNS, este servicio es administrable en su totalidad e incorpora una lista de direcciones, que para no ahondar mucho más en él, podemos decir que no se resolverán aunque tengamos una entrada host , alias, etc. creada.
El ejemplo más claro lo vemos cuando queremos publicar un servicio proxy pac vía dns y creamos la entrada, que debería resolver wpad.dominio.local por ejemplo.
Captura donde podéis ver que no podemos hacer ping a la dirección:
Gestión de la Blocklist
Comandos comunes en la gestión de este servicio son:
Por defecto tenemos en la lista wpad y Isatap:
Y tras el reseteo de la lista:
Hola.
Cuando instaláis una característica (Feature) o Rol en Windows Server 2012 o Windows 8, os podéis encontrar que sin conexión a internet o contando con una conexión filtrada a través de un proxy, no la activación de estas, no pueda realizarse.
Para solucionar este problema, debéis indicar una fuente de datos correcta ya que Internet, como tal, no es una posibilidad.
Por tanto:
1. Debéis descomprimir el Iso de Ws2012 y/o W8 o copiar el contenido del dvd en una carpeta.
2. Utilizar este comando para la activación de:
dism.exe /online /enable-feature /featurename:Feature /Source:Unidad:\sources\sxs /LimitAccess /all
Ejemplo .Net Framework:
dism.exe /online /enable-feature /featurename:NetFX3 /Source:e:\isos\sources\sxs /LimitAccess /all
Esta es una consulta más o menos común en los foros, pero atentos, pocas instrucciones dadas en estos, añaden la variable /all la cual habilita la activación de dependencias y por tanto, el comando falla fácilmente.
Saludos
Hola.
En Technet han actualizado la tabla con la lista de actualizaciones y hotfix sacados hasta la fecha para Hyper-V en Windows Server 2012
Aquí lo tenéis:
En este web también podéis encontrar algo similar en relación a actualizaciones y hotfix para el rol de Failover Clúster:
http://support.microsoft.com/kb/2784261
Saludos.
Hola.
Aunque ahora ya sabéis que en Windows Server 2012, puedes añadir o quitar la GUI -Interface gráfica de windows, la web que os enlazo a continuación, recopila los scripts y ordenes powershell necesarias para configurar un servidor en modo core:
http://technet.microsoft.com/en-us/library/jj592692.aspx
Saludos.
Hola.
La verdad es que no tenemos tiempo ni de celebrar lo bueno que nos pasa .
El otro día saqué el examen 70-417 que me actualiza a MCSA en Windows Server 2012.
Hasta el día del examen estuve haciendo una guía de estudio con los links que iba utilizando, esta guía no está terminada pero creo que aun sí, si os planteáis prepararlo puede ser una buena ayuda.
He colgado el código HTML directo al documento, pero como no se si está funcionando bien, os dejo también el link de la carpeta de skydrive donde está alojado.
https://skydrive.live.com/redir?resid=D0190B360D3CB440!153
Saludos.
Hola.
En esta entrada, vamos a crear un Scale Out específico para Hyper-V
1.Crear un Nuevo Rol de File Server
2. Elegir Scale-Out File Server for Application data
3. Dar nombre al Rol
4. Crear un File Share
5. Elecir el perfile SMB Share – Applications
6.Crear la ruta del File Share, la cual apunta a nuestro CSV
7. Dar nombre al Share, creando a su vez las subcarpetas en el CSV
8. Elegir las opciones posibles, alta disponibilidad por supuesto, como opcional podéis cifrar la información.
9. En los permisos, hay que añadir los host de hyper-V y los usuarios que van crear las máquinas como control total en el share.
Ahora solo quedaría crear la máquina. Es fácil, como podéis deducir, solo tenéis que crear tanto la máquina, como los discos, en la ruta del share que acabáis de crear, en mi caso \\scaleout\hypervms
Y la comprobación de funcionamiento es esta. Ante la caída de un nodo o el cambio de propiedad del csv, la máquina sigue levantada.
Consideración:
Tal y como he dicho en anteriores entradas, ahora, con ws2012, el clúster se levanta a pesar de no tener controlador de dominio de referencia. Digo esto porque es muy probable que como también podéis hacer ya, al estar soportado, es posible que el DC sea una de las máquinas virtuales alojadas.
Si cae el clúster, aunque este se levante para poder acceder a las carpetas el sistema debe validar que el usuario o máquina tiene permiso a la carpeta y como no tenéis DC, pues… problema. Aconsejo crear un usuario local en los nodos del clúster y ante la caída del DC, podréis entrar a los recursos compartidos, validandoos por smb desde los hyper-v host con el usuario local, con lo que los hosts ya podrían ver y por tanto levantar las máquinas virtuales.
Saludos.
Esta entrada es una copia exacta de la entrada del que ahora será mi blog: http://blogs.itpro.es/mhernandez
Hola.
Tras haber estado hablado en las últimas entradas sobre las novedades, principalmente, en la creación de clústeres, ahora tocaría hablar de la principal novedad en cuanto a funcionalidad, esto es, Scale Out.
Scale Out es el nombre que ha recibido la funcionalidad de almacenamiento clusterizado de archivos para aplicaciones que lo soportan. Scale out se combina con csv y por tanto nos ofrece mayor fiabilidad, disponibilidad, manejabilidad y alto rendimiento ya que la información se ofrece on line por parte de todos los nodos del clúster.
En esta entrada veremos la configuración de Scale Out para almacenar máquinas virtuales creadas en Hyper-V r3.
La comparativa entre Scale Out y la solución tradicional es esta:
http://technet.microsoft.com/es-es/library/hh831349.aspx
Antes de nada veamos los requisitos previos:
1. Tener un CSV dedicado en el clúster, que en ws2012 se crea así:
2. La cuenta de equipo de clúster ha de tener permisos de creación de cuentras de equipo en la OU donde está:
3. Tener los servidores de Hyper-V en el mismo dominio que el clúster o en dominios con relaciones de confianza.
En la siguiente entrada creamos el Scale out …