This morning we released d7x v18.3.17.1 (yay!) just as it became obvious that existing versions will not update, and most any d7xRDT packages will also fail to download or launch d7x.
If you have d7x v18.3.16.0 or above, your copy should update to today’s release without issue; not so with any previous releases.
Affected Versions
* d7x v18.2.3.0 and below will fail to communicate with our secure download site, including receiving even the notification of any new update availability. The result is that it will never know updates exist. d7x would also fail in debug submission uploads, although by using an email address with your submission (and checking the response requested option) it would still successfully make it to our support ticket queue.
* d7xRDT aka Remote Deployment Tool of most any 0.x.x.x version that is out there will also fail to communicate with our secure download site, returning a simple download failure error and aborting.
Not Affected
* Communication with other servers is unaffected, including those used for registering the d7x software and by the dCloud system for config/definitions storage (which is also used by d7xRDT, though a somewhat moot point.)
* Communication with other software (e.g. CryptoPrevent) is unaffected.
Resolution
The most current download is always available at the top of the d7x Manual and from this full package download you can simply extract the current “d7x\d7x v18.3.17.1.exe” (or higher) to your existing d7x directory, making sure to remove any prior d7x vx.x.x.x.exe files before running this current version.
Also in the full package download you will find “d7x\d7x Resources\d7xRDT v18.3.17.1.exe” which can be placed in your existing directories (also removing the existing versions of that file) although you may save this step since the current d7x in that package will properly download this (if missing) when you are creating a new self-extracting d7xRDT for usage.
To create a new d7xRDT (which btw now self-updates when deployed remotely, and is also working I might add) from the main interface in d7x, click the Servers drop down menu at the top, then select Config Mgmt Portal, and use the button on the bottom to create a new d7xRDT.
What happened?
The issue stems from an expired SSL certificate (on Feb. 26th) and it was far more of an issue than previously thought (doh!) New verifications are used by d7x to assure our server’s identity when establishing secure connections, and some additional checks reject the connection when the certificate is expired (even if the same cert is renewed.) Although this specific requirement should have been removed in the last few releases, it wasn’t, therefore leaving the previous certificate in place until most or all application updates were made would not achieve a desired result. Of course a new certificate is currently in use.
While these things happen from time to time, I personally couldn’t regret the issue any more than I already do. I cannot overstate the additional care to be taken in the future with regard to the security and the update process. For now, please accept a sincere apology for any inconvenience this may cause.
…
So what else is new with d7x?
d7x v18.3.17.1 has a lot of small fixes and features, and more complete list should soon make it to the d7x Manual, but here’s a few to inject some good news into this blog post.
- New: Technician Password correction prompts. When extracting an encrypted config archive, d7x will prompt if the technician password (used for archive encryption) is incorrect, allowing the option to retry as many times as necessary. Previously the extraction aborted/failed leaving a blank config, triggering the d7x registration prompt on launch. This has actually been an issue since d7 Premium with dCloud, but rarely a problem since typically no one changes that password. Also by having few options in d7/d7II/d7x that require it’s manual input, this is why it can easily be forgotten and not become an issue for quite some time. It usually takes a new major release (d7II, and now d7x) when those opting for the “clean download/setup” can bring this on with new configs created using different technician passwords entered during the initial registration process.
- Fixed: Failure to run scripts within custom app configurations that used the %scriptdir% variable to point outside of the 3rd Party Tools directory. Possibly other cases were an issue resulting from the bug. Further, some custom apps were failing without a download URL being configured.
- Fixed: d7x sometimes failed to restart itself along with Windows. Previous versions ran shutdown code which removed the startup entry responsible for launching d7x after a Windows restart; this also stalled auto mode operation until d7x was manually launched again.
- Fixed web links opening in the d7x internal browser despite being configured to use the system default web browser.
- Change: The titlebar previously forced the version display, ignoring user preference (this is by design for TestBuild and FastTrack releases, but removed in FastTrack currently until the Release follows soon.)
So what else is new with d7xRDT? (Remote Deployment Tool)
As stated previously, d7xRDT v18.3.17.1 will now self-update it’s own binary when deployed, ironically to ensure server connectivity with updates as changes are required. This was actually introduced for similar issues in the past with the d7II “SFX Mini” (the previous gen d7xRDT.)
Along the same lines, soon the d7xRDT will download d7x binaries from your own http-based URL (similar to using self-hosted FTP for config/definitions storage) as well as ours, in case of connectivity issues. In fact this version of the d7xRDT binary has the code in place as it was also planned prior to this incident, however a new d7x version will still be required to generate and embed the new self-hosted configuration inside the d7xRDT package which you will deploy with, as well as the appropriate d7x archive that you would host on your server.
Stay tuned for more…
