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.
How to Disable Admin Access to Zyxel from WAN
Zyxel recently announced a security vulnerability affecting their products. WAN access to the admin console is part of the problem. Here’s how to turn it off and walk through a remediation process.
Zyxel recently announced a security issue concerning its USG/ZyWALL, USG FLEX, ATP, and VPN series running on-premise ZLD firmware.
An aggressor capable of accessing the admin login from WAN can insert a new routing policy and new backdoor admin users. A full write-up and remediation process can be found here.
Currently, there’s no fix.
In the meantime, here’s how to disable admin access to console from WAN.
WARNING:
Once you take this step, you’ll have to access the web console from LAN so you’ll need to be behind the firewall to address it until you re-enable HTTPS on the WAN Service Group. You’ll want to do this on the LAN using a local machine, or, through using a VPN connection behind the firewall.
Login to the Zyxel as Admin.
Go to Configuration > Object > Service.
Select the Service Groups Tab.
Find the Default Allow WAN to Zywall Policy.
If HTTPS is in the Member Service Group, select HTTPS and remove it.
Strike the OK button and the configuration will be saved.
Your Zywall is now protected from the attack.
Recommendations from Here
Walk through the remediation article I cited above to see if your Zyxel product was affected by the attack.
Take the necessary remediation steps or prove that your device wasn’t affected.
Update your device’s firmware.
My Advice: Don’t trust the Cloud Update procedure inside of the device.
I find the Cloud Update in the GUI misreports highest firmware versions.
Confirm the actual version for your product by logging in to portal.myzyxel.com, accessing My Devices, and attempt to download the latest firmware. Compare version numbers for the active and standby partition.
If you need to update, upload the firmware manually to the standby partition with the option not to reboot when prompted.
The Zyxel should start the upload process (be patient, it’ll take a while) and it shouldn’t reboot on you (I’ve had several USG40’s that rebooted regardless).
If the device doesn’t auto-reboot, afterwards on your own schedule, reboot the device.
It’ll take the newer firmware in the standby partition as active, putting you on the latest release.
As of this time/date, Zyxel doesn’t have a fix yet but you’d want to repeat this procedure to manually update the fix firmware once it’s released. You should then be able to re-add HTTPS to the WAN Service Group.
R