Principales respuestas
Problema con la aplicacion de directivas

Pregunta
-
Hola.
Este es un problema que ya consulte, pero que aun no he conseguido resolver, ya que las soluciones que me han propuesto no eran aplicables. Por ejemplo una solución pedía ejecutar secedit /refreshpolicy, el cual no existe en Server 2003 y posteriores, y aunque trate de probar con GPUPDATE, no conseguí resolver el problema.
Explico de nuevo el problema, ya que he retomado el asunto a ver si consigo solucionarlo con vuestra ayuda.
El problema es en un domino con dos domain controller Windows Server 2003 R2, que quiero sustituir por Windows Server 2008 R2. La idea es hacer que los nuevos DC con 2008 sustituyan a los 2003, para retirarlos. En este dominio, hubo un problema con carpetas que se borraron por error (probablemente las de las policies), lo cual producía errores en el visor de sucesos periódicamente al intentar aplicar las policies. por lo que tuvimos que quitar las asignaciones de las policies en el dominio y en la OU domain controlers, y generar nuevas polcies, copiando como estaban configuradas en otro dominio sin problemas.
Para hacer el cambio, eleve el nivel del bosque y del dominio, que estaban en 2000 y 2000 mixto respectivamente, ambos a 2003. Ya no recuerdo en cual de los dos adprer32.exe fue, si en el foresprep o en el domainprep, obtuve errores como este:
Tipo de suceso: Error
Origen del suceso: SceSrv
Categoría del suceso: Ninguno
Id. suceso: 1003
Fecha: 26/03/2014
Hora: 17:05:04
Usuario: No disponible
Equipo: SAITEC05
Descripción:
Error al reintentar la notificación del cambio de directiva desde LSA/SAM. Error 4312 al guardar el cambio de directiva en los Objetos de directiva de grupo. Para obtener más información sobre la depuración, consulte security\logs\scepol.log en la raíz Windows.
Para obtener más información, vea el Centro de ayuda y soporte técnico en http://go.microsoft.com/fwlink/events.asp.Alguna soluciones me indican utilizar una aplicación llamada SidToName, pero como veis en el error, no dice que SID esta produciendo el error, por lo que no lo puedo usar.
Tampoco existe el fichero security\logs\scepol.log en la raíz Windows, por lo que no puedo examinarlo.
Sin embargo, si que existe el fichero Winlogon.log. Lo he renombrado, y he ejecutado GPUPDATE /Force, con lo que se ha generado un nuevo Winlogon.log. El error en el visor de sucesos no ha aparecido de nuevo, lo que me extraña. Solo se produjo al ejecutar el adprep32.exe, o cuando ejecute por ejemplo el DCPROMO de uno de los Server 2008.
El contenido del fichero, lo puse en la anterior consulta y me dijeron que hace referencia a un problema de seguridad con GPO_INFO_FLAG_BACKGROUND pero no se como resolverlo, ya que la solución propuesta, como digo no pude aplicarla (lo del secedit mencionado al principio). Pego el contenido de este log para ver si pueden por favor ayudarme de nuevo.
*************************
Error 0 para enviar el indicador de control 1 al servidor.
Hacer una copia local de \\informatica.local\SysVol\informatica.local\Policies\{67FA71CD-04E2-459F-8446-6C14E4E2E506}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf.
GPLinkDomain GPO_INFO_FLAG_BACKGROUND )
Hacer una copia local de \\informatica.local\SysVol\informatica.local\Policies\{F641E4CD-1D35-402E-9071-C2CCBAEBF9CD}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf.
GPLinkOrganizationUnit GPO_INFO_FLAG_BACKGROUND )
Procesar plantilla de directiva de grupo gpt00000.dom.
Éste no es el último GPO.
-------------------------------------------
jueves, 19 de junio de 2014 11:08:28
El usuario que inició la sesión tiene privilegios de administrador.
Analizando la plantilla C:\WINDOWS\security\templates\policies\gpt00000.dom.
Copiar valores de recuperación a la directiva combinada.
----Revertir la inicialización del motor de configuración...
Procesar plantilla de directiva de grupo gpt00001.inf.
Éste es el último GPO : la directiva de dominio se ha omitido en DC.
-------------------------------------------
jueves, 19 de junio de 2014 11:08:29
El usuario que inició la sesión tiene privilegios de administrador.
Analizando la plantilla C:\WINDOWS\security\templates\policies\gpt00001.inf.
----Revertir la inicialización del motor de configuración...
-------------------------------------------
jueves, 19 de junio de 2014 11:08:29
El usuario que inició la sesión tiene privilegios de administrador.
----El motor de configuración se inicializó correctamente.----
----Leyendo información de la plantilla de configuración...
----Configurar derechos del usuario...
SeNetworkLogonRight se debe asignar a la cuenta Controladores corporativos para que la propagación de directiva y la replicación sean satisfactorias.
Error al asignar SeSystemtimePrivilege a la cuenta Administradores. Es posible que esta configuración bloquee a los administradores cuando inicien sesión interactivamente.
Configurar S-1-5-21-682003330-1801674531-2146714087-500.
Configurar S-1-5-21-682003330-1801674531-2146714087-7611.
Configurar S-1-5-21-682003330-1801674531-2146714087-7612.
Configurar S-1-5-21-682003330-1801674531-2146714087-8606.
Configurar S-1-5-21-682003330-1801674531-2146714087-7610.
Configurar S-1-5-32-544.
Configurar S-1-5-32-551.
Configurar S-1-5-32-549.
Configurar S-1-5-21-682003330-1801674531-2146714087-1120.
Configurar S-1-5-21-682003330-1801674531-2146714087-3605.
Configurar S-1-5-21-682003330-1801674531-2146714087-1002.
Configurar S-1-5-21-682003330-1801674531-2146714087-3606.
Configurar S-1-5-21-682003330-1801674531-2146714087-2108.
Configurar S-1-5-21-682003330-1801674531-2146714087-1001.
Configurar S-1-1-0.
Configurar S-1-5-11.
Configurar S-1-5-21-682003330-1801674531-2146714087-501.
Configurar S-1-5-32-550.
Configurar S-1-5-32-548.
Configurar S-1-5-21-682003330-1801674531-2146714087-1000.
Configurar S-1-5-18.
Configurar S-1-5-20.
Configurar S-1-5-9.
Configurar S-1-5-19.
Se completó correctamente la configuración de derechos del usuario.
----Configurar directiva de seguridad...
Se completó correctamente la configuración de auditoría y el registro.
Se completó correctamente la configuración de directivas Kerberos.
Configurar machine\system\currentcontrolset\services\lanmanserver\parameters\enablesecuritysignature.
Ya hay un valor Deshacer para la configuración de directiva de grupo<machine\system\currentcontrolset\services\lanmanserver\parameters\enablesecuritysignature>.
Se completó correctamente la configuración de valores del Registro.
----Configurar los motores de anexión de datos disponibles...
Se completó correctamente la configuración de los motores de anexión de datos.
----Revertir la inicialización del motor de configuración...
Otras soluciones hablan de borrar y regenerar la cuenta que genera el problema, pero como digo, no se el SID, y tampoco se a que se refieren con borrar y regenerar la cuenta. Es decir, no se si se refieren a quitar y volver a poner la cuenta de la ficha seguridad de las carpetas en disco donde están las policies, o si se refieren a borrar la cuenta del dominio, pero si es por ejemplo la cuenta SYSTEM, eso no se si seria un desastre.
También trate de copia los permisos en todas las carpetas donde están las policies (en C:\Windows\SYSVOL\.........) poniendo los mismo permisos a los mismos usuarios, copiandolos de otro dominio que tengo si problemas, pero no funciono. Ni siquiera se si tenia lógica hacer esto o si tiene que ver con el problema.
Muchísimas gracias por vuestro tiempo, se que es un problema complicado, y puede que no puedan ayudarme, pero aun así, les agradezco cualquier intento. Espero haberme explicado bien, y no haberles molestado mucho por realizar una consulta de manera reiterada.
Gracias a todos.
Respuestas
-
Hola, Probador:
Ante todo, me alegra saber que mi escrito te ha servido de ayuda! No obstante, tras leer tu texto, creo que existen algunos detalles que nos pueden servir de ayuda para determinar el origen de los problemas. Te comento:
Lo primero y más importante: Existe la posibilidad de restaurar los directorios/ficheros eliminados del SYSVOL? Si tienes habilitado el servicio SHADOW, podrías recuperar los datos (auqne no te voy a engañar: personalmente nunca lo he hecho así..)
Creo que es contraproducente pretender ejecutar la herramienta ADPREP (o ADPREP32.. se supone que no hay diferencia!) con la variable RODPREP, ya que éste parámetro esté pensado para ejecutarse en DC's de sites asociados de "solo lectura".. lo cual interpreto que no es el caso. Te recomiendo que de la herramienta ADPREP32, ejecutes únicamente las variables /FORESTPREP y /DOMAINPREP (ésta última con la variable adicional /GPPREP, ya que *precisamente* adapta (para entendernos) las GPO de dominio a la nueva versión del SO. Dicho de otra manera, ejecuta las herramientas en éste orden:
<UNIDAD>:\SUPPORT\ADPREP\ADPREP32.exe /DOMAINPREP /GPPREP
<UNIDAD>:\SUPPORT\ADPREP\ADPREP32.exe /FORESTPREP
Por favor.. NO ejecutes la variable /RODCPREP, ya que en el caso en que le de el "telele" al servidor y se ejecute, NO podrás hacer cambios serios en la consola AD..
No te líes por la.. limpieza de datos en el DC2k8. En el momento en que lo sincronices con el Maestro de Infraestructura actual, se va a llenar de *detritus* hagas lo que hagas, por lo que te sugiero te centres en proceder correctamente a la migración de los servidores y del esquema AD.. Y LUEGO, cuando los FSMO, el DNS, el DHCP (si hubiere) y demás herramientas estén correctamente migradas al nuevo DC, ya te encargas de limpiar tanto las GPO de dominio como los Objetos huérfanos del AD..
Más que nada, para que cuando tu jefe te pregunte cómo va la cosa (que lo hará.. y lo sabes!!) puedas mostrarle las pequeñas evoluciones que hayas realizado.Desiderio Ondo | Bachellor Science in Computer engineering | MCSE 2k3 certified | ITIL certified
- Propuesto como respuesta Desiderio Ondo jueves, 26 de junio de 2014 16:59
- Marcado como respuesta Probador Software viernes, 27 de junio de 2014 9:04
Todas las respuestas
-
Una observación que acabo de ver.
En Usuarios y equipos de AD, si activo ver características avanzadas, dentro de System->Policies, hay un montón de objetos con ID tipo {31B2F........}, que no existen luego en la carpeta C:\WINDOWS\SYSVOL\sysvol\informatica.local\Policies.
¿Podría ser ese el problema? Es decir, ¿podría ser que este intentando aplicar cambios a policies de los que no existe en contenedor en disco?
¿Puedo borrar la estradas en Usuarios y equipos de AD que no existan en C:\WINDOWS\SYSVOL\sysvol\informatica.local\Policies?
-
Sigo avanzando.
Me he fijado que de esos Group Policy Containers, algunos los he podido eliminar, pero otros no.
Creo que los dos que no puedo eliminar, son las policies por defecto que crea AD al ejecutar DCPROMO.
Hay una utilidad para restaurar las policies por defecto, llamada DCGPOFIX, pero me dice que la versiondel esquema no es compatible.
Esto seguro que es por haber ejecutado en el 2003 el ADPREP32 /FORESTPREP y el ADPREP32 /DOMAINPREP
Aunque hay un parametro que me permite ignorar la version del esquema, me advierte que el comportamiento puede ser impredecible, y que trate de buscar una version de la herramienta compatible con la version del esquema.
¿Se os ocurre que puedo hacer?
Gracias.
-
Hola!
Menudo rollo por lo que veo. Finalmente entonces no se logró elevar el nivel funcional? o se logró elevar y posteriormente empezó a presentar estos errores?
Para empezar es muy importante solucionar el problema de las GPOs, tienen que restaurarse, te dejo este enlace a una herramienta para nivel funcional nativo http://www.microsoft.com/en-us/download/details.aspx?id=15020
Por otro lado, sería ideal hacer un DCDIAG y mostrar los resultados!
Vamos paso a paso hasta dar con el clavo.
Saludos,
Jesús Peñaranda| MCP,MCT,MCTS,MCITP,MCSA,MCSE
-
Gracias por responder.
El nivel funcional parece que se elevo. Por lo menos, me dice que esta en modo Server 2003, tanto en el bosque como en el dominio.
Después de elevar el nivel, con el comando adprep32 /forestprep, creo recordar que no tuve ningún problema. Con el parámetro domainprep, creo recordar que tampoco, aunque se produjo posteriormente el error que menciono con un par de sucesos en el visor. Pero estos sucesos, no se repiten periódicamente, simplemente se produjeron después del ADPREP32.
El que no pude ejecutar fue el ADPREP32 con el parámetro /RODCPREP, ese me dio problemas y no lo ejecuto.
El DCDIAG lo postee anteriormente, pero no mostraba ningún problema. Puedo volver a postearlo si quieres, pero como te digo, no mostraba problemas.
Lo que creo que podría solucionar el problema es ejecutar el DCGPOFIX, pero no quiero usar el parámetro que ignora la versión del esquema, ya que al intentar ejecutarlo, me avisa que la versión del esquema no se corresponde con la de la herramienta. Esto creo que es debido a que realice como digo el forestprep y el domainprep, con lo que cambio el esquema, y la herramienta de server 2003 es inferior.
Mi duda es si puedo copiar el DCGPOFIX de un server 2008 r2, y ejecutarlo sobre el DC con server 2003 para que lo haga, ya que el DCGPOFIX de 2003, tiene el problema mencionado.
Otra opción es hacer DC a un 2008 r2 y ejecutarlo ahí, pero no se si es mejor resolver lo de las policies ejecutando el DCGPOFIX que trae 2008 en el DC con 2003, antes de convertir el 2008 en DC.
Gracias de nuevo por responder, porque como tu has dicho, es un rollo de la pera, y entiendo que es todo un reto.
Como digo, creo que todo el problema viene de un error accidental por el que se borraron las carpetas que contenían los GPO en SYSVOL.
-
Hola,
Definitivamente una copia fresca de DC sobre Windows Server 2008 podría ser de mucha ayuda, desde ahí mismo puedes usar el DCGPOFIX, el se encargará de actualizar esa información en el AD.
Me llama la atención que te de ese error relacionado con la version del Schema cuando ejecutas DCGPOFIX, da la sensación de que no tuviera registrado la versión 2003.
Saludos,
Jesús Peñaranda| MCP,MCT,MCTS,MCITP,MCSA,MCSE
-
Hola, Probador:
Lo primero y más importante, compañero: En el momento de anexar un equipo nuevo al dominio (o incluso al migrar/actualizar el SO de los servidores), NO es conveniente eliminar manualmente nada de los directorios "sagrados" del sistema: NTDS y SYSVOL, ya que aunque el entorno AD 2k8 detecta la existencia de registros en las directivas que han sido cambiados/modificados, lo idóneo es aplicar las herramientas desarrolladas (ejem! "compradas") por MS para completar correctamente el proceso.
Para tu caso concreto, te recomiendo primero deshabilites TODAS las GPO (a excepción de las críticas) antes de empezar nada. Por supuesto, deberás hacerlo en un momento de la semana en que no hayan usuarios conectados, para asegurarte que no hayan transacciones de red..
.- Bien, lo primero es recopilar los datos que tenemos en la red actual para saber qué tenemos. Para no extenderme, te sugiero sigas los datos señalados en:
-Recopilación de datos en una red:
http://technet.microsoft.com/es-es/library/dd379556%28v=ws.10%29
.- Ejecuta la herramienta (ejecutar => RSOP.msc) o (ejecutar => GPRESULT.msc) para comprobar qué GPOs se ejecutan en cuentas de máquinas y/o usuarios. Desasignalas para que no causen problemas posteriores. Luego lo restauraremos otra vez..
.- Instala el SO "en limpio" desde la que será el nuevo DC (para abreviar, lo llamaremos DC2k8) y asegúrate que tiene conexión a la red actual, pero NO le instales nada adicional.. todavia.
.- Accede al DC actual (llamaremos DC2k3) y asegúrate que los procesos DCDIAG, REPADMIN /SHOWREPS y GPOTOOLS (por este orden) se ejecutan correctamente y no hayan errores de conexión, al menos..
Ahora empieza lo bueno:
.- Desde DC2k3, prepara el dominio para 2k8 => Desde el prompt del sistema, accede a la unidad del lector CD/DVD de tu equipo (al que habremos insertado el CD o .ISO del MS w2k8) y ejecuta:
<UNIDAD>:\SUPPORT\ADPREP>ADPREP.exe /DOMAINPREP /GPPREP
<UNIDAD>:\SUPPORT\ADPREP>ADPREP.exe /FORESTPREP
.- Configura los DNS tanto en DC2k3 como en DC2k8 para que "apunten" al DNS actual (presumo DC2k3..)
.- Desde DC2k8, procede a ejecutar DCPROMO /ADV para promocionarlo como DC adicional al dominio existente. Asegúrate de instalar tambien la consola DNS..
.- Desde DC2k3, transfiere los roles FSMO asignando DC2k8 como receptor. Creo que los pasos más sencillos (forma gráfica) sería desde http://support.microsoft.com/kb/324801/es-es
.- Desde DC2k3, accede a la consola DNS (ejecutar => DNSMGMT.msc) y asegúrate que en la solapa "servidores de nombre" está registrado DC2k8. Después, desde ejecutar => NCPA.cpl establece en ambos servidores (y por ende, en TODOS los servidores que DNS1 sea DC2k8.
.- Desde DC2k3, ejecuta la herramienta DCPROMO para despromover dicho server como DC, y una vez completado el proceso, accede a DC2k8 y con la herramienta ejecutar => ADSIEDIT.msc elimina los registros "huérfanos" que hayan quedado de DC2k3. Para ayudarte, sigue las indicaciones de la URL oficial de Microsoft (eso si: con MUCHO cuidado!).
· Uso de ADSIEDIT:
http://technet.microsoft.com/es-es/library/cc773354%28WS.10%29.aspx
Muy bien! Para confirmar que todo ha salido bien, lo recomendable es desconectar físicamente de la red DC2k3 durante un mínimo de 24h y verificar qué servicios pueden.. "quejarse". Normalmente, suelen ser DHCP y DFS (si los tenemos instalados), los cuales sólo habría que cambiar los parámetros delDC al nuevo DC2k8..
En todo caso, el proceso es mucho más sencillo de lo que yo te pueda decir. Recomiendo lo hagas durante un periodo mínimo de 3 días en que casi no hayan usuarios en la red (ahora en Verano es perfecto!) y dispongas de un tiempo extra por si se presentan complicaciones.. Sea como fuere, he aquí la documentación oficial de Microsoft para que completes correctamente el proceso:
· Migración de dominios ADDS a MSw2k8 y MSw2k8R2:
http://www.microsoft.com/en-us/download/details.aspx?id=6170Desiderio Ondo | Bachellor Science in Computer engineering | MCSE 2k3 certified | ITIL certified
- Propuesto como respuesta Desiderio Ondo miércoles, 25 de junio de 2014 18:21
-
Hola.
Antes de nada, gracias por responder a todos.
Respondo primero a Jesus.
En el 2003, que es el DC con los roles FSMO, no es que no reconozca el comando DCGPOFIX, si no que me dice que la versión de esquema no es la misma que la de la herramienta. Es decir, que no coincide la versión del esquema, con la versión de DCGPOFIX, o así lo entiendo yo.
Pero esto no me extraña, es normal que de este error, ya que no coincide la versión de esquema, porque había ejecutado ya el comando ADPREP32.EXE /FORESTPREP y ADPREP32.EXE /DOMAINPREP que te cambian cosas en el esquema. Por lo tanto, mi duda era si podía usar el archivo DCGPOFIX.EXE de un Server 2008 R2 y utilizarlo en en Server 2003, o es mejor añadir un DC 2008 R2 y ejecutarlo desde el DC con 2008 R2.
Ahora respondo a Desiderio.
Gracias por la explicación tan completa. De todos modos, no se borraron las carpetas de sysvol donde están los GPO a propósito como parte de la migración, fue algo accidental. Cuando se produjo este error, lo que hice fue desvincular del dominio, el link a la GPO por defecto del dominio, y en la OU de Domain Controlers, también desvincule la GPO por defecto. Con esto quedo todo sin ninguna GPO asociada.
Cree dos GPO nuevos, y copie una por una, todas las configuraciones de directiva, de otro dominio que tengo. No he aplicado apenas cambios a las GPO por defecto, mas que configurar alguna opciones del proxy de Internet Explore, por lo que me valen las configuraciones por defecto.
Con esto me desaparecieron los errores del visor, hasta que intente migrar al 2008 R2, ya que los errores del visor de sucesos, se produjeron al elevar el nivel del bosque y del dominio a Server 2003 (estaba en nivel 2000 mixto y 2000) y al ejecutar el ADPREP32.EXE /DOMAINPREP. El ADPREP32.EXE /RODCPREP no se ejecuto porque da error, seguro que por esto. Es casi seguro por lo que explico en el primer post, y por eso quería regenerar los GPO por defecto, ya que creo que los errores del visor son porque no encuentra los objetos GPO que en AD parecen existir (los GPO por defecto no se pueden eliminar de AD).
Por lo tanto, creo que ya estoy siguiendo o he ejecutado ya, parte de las instrucciones que me das y que te agradezco de verdad. Por ejemplo se los nombres de los DC completos FQDN, las IP, he desvinculado los GPO, se quien tiene los FSMO (todos el server 2003), es catalogo global, DNS..... Las herramientas DCDIAG, REPADMIN /SHOWREPS, ..... en principio se ejecutan sin problema.
La idea es que antes de seguir promocionando con DCPROMO el Sever 2008 R2 (ahora es servidor miembro), quería saber si puedo resolver esto para poder ejecutar el ADPREP32.EXE /RODCPREP.
Por cierto, ejecuto el ADPREP32.EXE en vez de ADPREP, porque el server 2003 es 32 bits, y el ADPREP por defecto de 2008 R2 es de 64 bits.
Cuando resuelva esto, promocionare el server 2008 R2 a DC, le pasare los FSMO, configurare los DNS de los equipos miembros para que apunten al DNS del 2008 R2, y despromocionare con DCPROMO el Server 2003.
Creo que es el proceso que me propones, si no te he entendido mal, pero el problema es precisamente que antes de promocionar el 2008 R2 a DC, quería ver si es posible arreglar el tema de los GPO que se borraron por error.
Gracias, sigo intentándolo ;-)
-
Hola, Probador:
Ante todo, me alegra saber que mi escrito te ha servido de ayuda! No obstante, tras leer tu texto, creo que existen algunos detalles que nos pueden servir de ayuda para determinar el origen de los problemas. Te comento:
Lo primero y más importante: Existe la posibilidad de restaurar los directorios/ficheros eliminados del SYSVOL? Si tienes habilitado el servicio SHADOW, podrías recuperar los datos (auqne no te voy a engañar: personalmente nunca lo he hecho así..)
Creo que es contraproducente pretender ejecutar la herramienta ADPREP (o ADPREP32.. se supone que no hay diferencia!) con la variable RODPREP, ya que éste parámetro esté pensado para ejecutarse en DC's de sites asociados de "solo lectura".. lo cual interpreto que no es el caso. Te recomiendo que de la herramienta ADPREP32, ejecutes únicamente las variables /FORESTPREP y /DOMAINPREP (ésta última con la variable adicional /GPPREP, ya que *precisamente* adapta (para entendernos) las GPO de dominio a la nueva versión del SO. Dicho de otra manera, ejecuta las herramientas en éste orden:
<UNIDAD>:\SUPPORT\ADPREP\ADPREP32.exe /DOMAINPREP /GPPREP
<UNIDAD>:\SUPPORT\ADPREP\ADPREP32.exe /FORESTPREP
Por favor.. NO ejecutes la variable /RODCPREP, ya que en el caso en que le de el "telele" al servidor y se ejecute, NO podrás hacer cambios serios en la consola AD..
No te líes por la.. limpieza de datos en el DC2k8. En el momento en que lo sincronices con el Maestro de Infraestructura actual, se va a llenar de *detritus* hagas lo que hagas, por lo que te sugiero te centres en proceder correctamente a la migración de los servidores y del esquema AD.. Y LUEGO, cuando los FSMO, el DNS, el DHCP (si hubiere) y demás herramientas estén correctamente migradas al nuevo DC, ya te encargas de limpiar tanto las GPO de dominio como los Objetos huérfanos del AD..
Más que nada, para que cuando tu jefe te pregunte cómo va la cosa (que lo hará.. y lo sabes!!) puedas mostrarle las pequeñas evoluciones que hayas realizado.Desiderio Ondo | Bachellor Science in Computer engineering | MCSE 2k3 certified | ITIL certified
- Propuesto como respuesta Desiderio Ondo jueves, 26 de junio de 2014 16:59
- Marcado como respuesta Probador Software viernes, 27 de junio de 2014 9:04
-