none
Uso de dnscmd /ageallrecords

    Question

  • Buenas,

    Necesito cambiar el time stamp de los registros de una zona antes de poner en marcha el scavenging. Esta configurado en la configuración del servidor con 365 para borrar los registros obsoletos- por cierto ¿Cuál es valor máximo en días que se puede poner?-. También esta configurado en la zona los periodos de refresco y actualización a 7 días. Es una zona integrada en dominio Windows 2008 R2 SP1 con nivel funcional Windows 2003.

    Al ejecutar el ageallrecords la respuesta es que se ha ejecutado bien, pero no cambia la fecha.. ¿alguien me puede decir cual es el motivo?

    Gracias,

    Amparo

    Thursday, April 18, 2013 6:00 PM

Answers

  • No estoy seguro aunque puede estar relacionado, segun como tengas configurado  Aging and Scavenging, si los registros estan en el periodo de "No Refresh" el timestamp no va a ser cambiado, por lo cual asumiendo que tu No refresh sea  7 dias, y tu Refresh 7 Dias , deberias encontrar junto el momento despues de los primeros siete dias de no-refresh ,  y antes de las siguientes  24 horas donde se efectuaria aproximadamente el dynamic update ...

    La siguiente nota es una muy buena fuente explicando el proceso de Aging and Scavenging.
    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    "The third way to set scavenging on records is by using DNScmd.exe with the /ageallrecords switch.  Let's pause here for a few moments to consider a few important words: All, Records, Delete, Stuff.  If you actually run this command against a zone it will truly set scavenging and a timestamp on all records in the zone including static records that you never want to be scavenged.  Because of the time it takes scavenging to do it's thing people find this command and get tempted to give it a try.  Do not.  It will delete stuff.  Have patience instead."

    Por otro lado, es recomendado en general  utilizar los valores default de 7 dias , si quieres acelarar el proceso bajar el tiempo de No Refresh, podria dar resultados mas rapidos, por otro lado si lo que quieres es reducir riesgos, puedes sacar una lista de tus registros mediante algun script, y verificar si hay algun timestamp antiguo ( > 7 dias ) antes de embarcarte en este proceso, ya que de esta manera podrias reducir riesgos de borrados innecesarios al momento de la primera corrida del proceso.



    Sebastian del Rio [MSFT] - Premier Field Engineer This posting is provided "AS IS" with no warranties, and confers no rights.


    Friday, April 19, 2013 9:46 AM

All replies

  • No estoy seguro aunque puede estar relacionado, segun como tengas configurado  Aging and Scavenging, si los registros estan en el periodo de "No Refresh" el timestamp no va a ser cambiado, por lo cual asumiendo que tu No refresh sea  7 dias, y tu Refresh 7 Dias , deberias encontrar junto el momento despues de los primeros siete dias de no-refresh ,  y antes de las siguientes  24 horas donde se efectuaria aproximadamente el dynamic update ...

    La siguiente nota es una muy buena fuente explicando el proceso de Aging and Scavenging.
    http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

    "The third way to set scavenging on records is by using DNScmd.exe with the /ageallrecords switch.  Let's pause here for a few moments to consider a few important words: All, Records, Delete, Stuff.  If you actually run this command against a zone it will truly set scavenging and a timestamp on all records in the zone including static records that you never want to be scavenged.  Because of the time it takes scavenging to do it's thing people find this command and get tempted to give it a try.  Do not.  It will delete stuff.  Have patience instead."

    Por otro lado, es recomendado en general  utilizar los valores default de 7 dias , si quieres acelarar el proceso bajar el tiempo de No Refresh, podria dar resultados mas rapidos, por otro lado si lo que quieres es reducir riesgos, puedes sacar una lista de tus registros mediante algun script, y verificar si hay algun timestamp antiguo ( > 7 dias ) antes de embarcarte en este proceso, ya que de esta manera podrias reducir riesgos de borrados innecesarios al momento de la primera corrida del proceso.



    Sebastian del Rio [MSFT] - Premier Field Engineer This posting is provided "AS IS" with no warranties, and confers no rights.


    Friday, April 19, 2013 9:46 AM
  • Gracias!!!

    Voy a  probar a ver cambiado el borrado de datos obsoletos y los periodos de actualización y refresco de a 4 días.

    Friday, April 19, 2013 2:53 PM