UPDATE: The original server is now back up. We still recommend the d7xRDT Fix below as a precautionary measure.
Early this morning our server used by the d7x Remote Deployment Tool and dSupportSuite (legacy dCloud hosted services only) failed, and (as a great reminder to test backups) our recent backups are also failing to initialize and allow connections from the d7xRDT. We do apologize for the inconvenience!
While we do plan to continue efforts to restore the original server, we recognize that downtime is unacceptable.
d7x Remote Deployment Tool – FIX:
A new d7xRDT has just been released to use two additional servers (3 in total), which have been setup to serve the d7xRDT and additional d7x files. In order to use the additional servers, you will need to recreate your d7xRDT with the latest version.
To ensure you have the latest version, check for the file .\d7x Resources\d7xRDT v188.8.131.52.exe and if it does not exist, End Session with d7x and restart d7x, which should then update itself and all modules including the d7xRDT to the latest versions. Once you ensure you have this file, you can recreate d7xRDT through the Servers menu > Config Mgmt Portal in d7x.
dSupportSuite (legacy dCloud hosted services):
A backup server was already been in place, which will be available to your dSupportSuite Mgmt Console as soon as DNS changes propagate down to your ISP (or preferred) DNS servers. DNS typically propagates in around 3 hours, but 3 days is a better bet to expect complete worldwide propagation. Client PCs will also need to retrieve the new server address from their DNS servers in order to receive configuration updates, which will happen soon after DNS propagates to them.
You can run “ipconfig /flushdns” from an elevated command prompt to flush existing DNS cache on the local PC running your dSupportSuite Mgmt Console, which should force a recheck from your DNS servers, otherwise you can expect up to an hour for DNS to be refreshed for that address.