Ask the Community
Groups
Debugging Strategy for Windows Instant Recovery Verify failures - Connect IT Community | Kaseya
<main> <article class="userContent"> <h2 data-id="summary"><strong>SUMMARY</strong></h2> <p>Debugging Strategy for Windows Instant Recovery Verify failures</p> <h2 data-id="issue"><strong>ISSUE</strong></h2> <p></p> <h3 data-id="purpose"><span style="font-size: medium;">Purpose</span></h3> <p><span style="font-size: medium;">Explain debugging procedure for Windows Instant Recovery (WIR) Verify failures. </span>Note this KB article doesn’t give detailed instructions on how to execute the debugging steps, but gives an overall debugging strategy. Specific debugging steps for specific types of problems are explained in other KB articles.</p> <h3 data-id="description"><span style="font-size: medium;">Description</span></h3> <p><span style="font-size: medium;">When a WIR instance is set to email a verification report after restores, the system will periodically boot the instance in “Verify Mode” to attempt to determine if the WIR VM is being restored properly. </span>When an instance is routinely sending verify failure emails, it can be difficult to determine the source of the problem.</p> <h3 data-id="cause"><span style="font-size: medium;">Cause</span></h3> <p><span style="font-size: medium;">The WIR email verification process includes booting the instance with a virtual network adapter, waiting for the adapter to get an IP address from a virtual DHCP server, connecting to the Windows Agent, then taking a screenshot of the login screen, which is saved and emailed to everyone on the appliance’s email address list. </span>A verify failure means for some reason the restore process could not connect to the Windows agent. Debugging the problem means finding the reason why the connection could not be established between the appliance and the agent running in the WIR instance.</p> <p><span style="font-size: medium;">Some of the more common connection failure causes are:</span></p> <p><span style="font-size: medium;">1.</span> <span style="font-size: medium;">There is a problem with the restores that causes the VM to be unable to boot.</span></p> <p><span style="font-size: medium;">2.</span> <span style="font-size: medium;">The WIR VM boots too slowly and the verify procedure times out before a connection can be established with the agent.</span></p> <p><span style="font-size: medium;">3.</span> <span style="font-size: medium;">The drivers are not available for the virtual network adapter, and it is therefore not functional after the VM boots.</span></p> <p><span style="font-size: medium;">4.</span> <span style="font-size: medium;">The virtual network adapter gets installed properly, but cannot get a DHCP address from the virtual DHCP server.</span></p> <p><span style="font-size: medium;">5.</span> <span style="font-size: medium;">The client has a firewall setting that prevents a connection to the virtual client through the virtual network adapter.</span></p> <h3 data-id="resolution"><span style="font-size: medium;">Resolution</span></h3> <p><span style="font-size: medium;">The default timeout for a verify attempt is 3 minutes. </span></p> <p><span style="font-size: medium;">The debug procedure will differ with each issue, but the following may provide a meaningful general procedure:</span></p> <p><span style="font-size: medium;">1.</span> <span style="font-size: medium;">Verify the virtual machine is booting up in Verify mode. </span>You will either need to increase the timeout value by modifying the master.ini file (by adding the MaxQemuBoot key – value is in seconds), or start up the VM manually from the command line (the procedure for doing this is the topic for another KB article). If after a reasonable time, the VM is not booting to a login prompt, then there is likely something wrong with the restores.</p> <p><span style="font-size: medium;">2.</span> <span style="font-size: medium;">If the VM is booting to the login prompt in Verify mode, login and after a couple of minutes, verify that the network adapter was set up and has received an IP address from the virtual DHCP server (using ipconfig from the command line). </span>If the network adapter never gets injected into the WIR instance, then it is likely the driver is missing on the virtual client. </p> <p><span style="font-size: medium;">If the network adapter gets set up correctly, but never gets an IP address from the DHCP server, then that is the problem. </span>You should begin debugging the problem on the appliance by checking the following:</p> <p><span style="font-size: medium;">·</span> <span style="font-size: medium;">Is the port security level set higher than “No Security”? </span>If so, change it to “No Security”.</p> <p><span style="font-size: medium;">·</span> <span style="font-size: medium;">Is there an IP address assigned to the WIR instance in the /var/run/qemu-dnsmasq-qemubr.leases file? </span>If so, then why isn’t the WIR instance getting it?</p> <p><span style="font-size: medium;">·</span> <span style="font-size: medium;">Is there a firewall issue on the WIR instance preventing it from getting a DHCP IP address?</span></p> <p><span style="font-size: medium;">3.</span> <span style="font-size: medium;">If the network adapter is set up and has an IP address within the default 3 minute timeout period, verify you can connect to the agent from the command line on the appliance (telnet :1743). </span>You should receive output that looks something like this:</p> <p>[root@Recovery-822 logs.dir]# telnet 192.168.55.23 1743</p> <p>Trying 192.168.55.23...</p> <p>Connected to 192.168.55.23 (192.168.55.23).</p> <p>Escape character is '^]'.</p> <p>¥A,Connect1745quit</p> <p><span style="font-size: medium;">If the network adapter does not obtain an IP address within the 3 minute default timeout period, but eventually does obtain one, then you have several options to resolve the issue:</span></p> <p><span style="font-size: medium;">·</span> <span style="font-size: medium;">Increase the timeout value</span></p> <p><span style="font-size: medium;">·</span> <span style="font-size: medium;">Give the WIR instance additional resources, i.e. increase the number of processors allocated to it, or give it additional virtual RAM. </span>After making the modification, reboot in Verify mode and observe whether the IP address is assigned more quickly during boot.</p> <p><span style="font-size: medium;">4.</span> <span style="font-size: medium;">If the WIR instance is getting an IP address within the default timeout period, and you can connect to port 1743 using telnet from the command line, then you should look in the logs on the WIR instance and the appliance for the source of the problem.</span></p> </article> </main>