Duplicati: Failed to Get Nonce
Duplicati is a great data backup utility. However, if you’re receiving a Failed to Get Nonce error message, or are having trouble logging in, there may be a quick fix. Here’s what to do.
Maybe you’re like me and you use Duplicati to target cloud and local storage for backups.
However, you attempted to login to Duplicati through the interactive stub in the Systems Tray and attempted to login, only to receive a cryptic error: Failed to Get Nonce.
The error indicates that the browser is using a cached version of the login page. The nonce system was used up until 2.0.8.1, but is not used in 2.1.0.1+. It should be easy to resolve with a forced reload (Shift+F5) in Chrome, or, dump the cache. Try again.
But let’s say you’re still experiencing the problem and can’t login to your localhost:8200 (http://localhost:8200/ngax/index.html). Drop to DOS with an elevated command prompt and try this command:
"C:\Program Files\Duplicati 2\Duplicati.Server.exe" --webservice-password=1234 --server-datafolder "C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati"Then try to login to the localhost:8200 with 1234. You can change the password again once you’re in.
But let’s say you’re still encountering problems with its access token, and you’ve got the Windows service for Duplicati loaded. Try this:
Clear/preserve your Application Log in Event Viewer.
Go into services.msc and stop the Duplicati Server service.
Start the Duplicati Server service.
Go into the Application Log.
You might see events entered by Duplicati that it was unable to start the 8200 instance because of a problem with its keys. It will provide a link to reset those keys within the event details.
Click on that and you’ll be walked through a reset.
Now, maybe you’re playing with multiple instances. Look closely. If you accessed Duplicati’s web-based UI from the stub, you might be in the localhost:8300 instance of Duplicati. Yes, confusing; the Windows Service, by default, only works against the 8200 instance, so if you ever wondered why your backups configured in the 8300 instance aren’t automated and working — that’s why. So how do you fix that? Try this:
Access the 8300 instance.
Export your backup configs to a *.json file.
Log out of the 8300 instance.
Access the 8200 instance using that localhost:8200 command from earlier.
Import your backup config.
When it runs for the first time, it’ll report a problem with the database. Run the repair option. It’ll rebuild your local database.
After, you’ll be ready to run your backups again under the 8200 instance which is processed by the Windows service.
Delete the backup in the 8300 instance.
R
Google Data Migration Service START Button Grayed Out
So, maybe you’re like me.
You’ve got a 100 or so user’s mailboxes you need to migrate from Microsoft 365 to Google Workspace.
You’ve completed your setups; the impersonation rights are set on your global admin in M365, and, you’ve assigned full control rights over all target mailboxes.
You strike up Workspace and start the Data Migration Service, successfully authenticate, and start adding users, but it won’t let you. You’ve got a GRAY START BUTTON like this.
And it’s frustrating the hell out of you because, hey, you’re a good tech, you did your planning, etc.
Well, I found a solution.
What’s happening here is that you’ve authenticated this process under another domain and not the domain you think you’re targetting. The oAuth token isn’t being saved under the right account or domain.
For me, I was in my Google Reseller console trying to kick this off, and the damn thing was trying to target my own domain rather than the tenant’s domain.
So, kill the data migration.
Login to the admin console under a Super Admin for your domain under an incognito window and set up the Data Migration Service parameters again.
You should now be able to target a user by typing … it matches, you can press start.
There’s nothing like this in the docs, of course, but hey, I just pulled my hair out for an hour … maybe I can help save yours :)
R
Microsoft L2TP Client Work-Around
Microsoft broke its own L2TP Client with its January 2022 roll-up patches. Here’s a quick fix to both keep the roll-ups as well as to allow L2TP VPN’s to work normally on a Windows 10 or Windows 11 computer.
On January 11, 2022, Microsoft released Windows 10 KB5009543 and Windows 11 KB5009566 as a part of their January 2022 roll-up. After applying the patches, administrators found that L2TP connections from remote Windows computers using the L2TP client would fail on connection.
At the time of this writing, Microsoft hasn’t pulled the roll-up and hasn’t issued a hotfix, suggesting instead that the IPSEC server be modified to disable the VendorID field in negotiation.
As this isn’t an option for most firewalls and would require vendors to post firmware updates for tens of thousands of product SKU’s, this effectively turned this problem into a pissing match between hardware vendors and Microsoft. Hardware vendors claim this is a Microsoft issue and advise customers to reverse the patch; Microsoft claims their implementation of the IPSEC client is correct. Meanwhile, VPN’s for millions of people working from home don’t work.
Reversing the patch may not be a suitable option when dealing with classified networks; as a system administrator, I’ve an obligation to apply Microsoft’s roll-ups to protect my clients’ data and network. Doing so may not only jeopardize IT assets that I’m responsible for but may just invalidate cyberinsurance policies because I did the exact opposite that I was supposed to do: I sacrificed a bunch of security patches in favor of one working feature; a feature that would break again unless I disabled patching on a remote machine, only exacerbating the problem over time.
The real fix for this, then, is for Microsoft to either pull the patch or issue a hotfix. Since Microsoft is (again) not stepping up to address messes that it makes, there’s a good work-around.
On a machine that doesn’t have the KB updates mentioned above (or reverse the KB on the affected machine), find the file c:\windows\system32\ikeext.dll. It’ll be dated 2021.
Copy this file out to where you have a copy of it.
Apply the Jan 2022 patches and reboot.
You’ll now find a 2022 version of ikeext.dll in the c:\windows\system32 folder.
Take control of that file by changing its ownership to a local administrator (perhaps the user account you’re using), and change your permissions to Full Control.
Using Task Manager, under the Services Tab, find ikeet.dll and stop it.
Rename c:\windows\system32\ikeext.dll to *.old, providing administrator elevation to do so.
Copy in your 2021 version of ikeext.dll to the same path.
Restart the ikeet.dll under the Services Tab or reboot the machine.
You’ll find that your L2TP VPN will now work, keeping the Jan 2022 patches and isolating the roll-back to just one DLL.
R
** Update: Microsoft has now issued a out-of-band update KB5010793 to address this issue.