We use Azure AD as our IdP as well, would love to see the login integrated as well.

1 User to 1 Customer, we have a primary contact person for each customer and that's who we set up. We manage the whole thing anyway so we only do this so that if someone wants to leave and "own" the backup we can give them the login so that whoever is taking over can check the configuration and match it if they choose. Luckily, it's never happened.

In case anyone else runs into this issue, this should have been put into the documentation but since it isn't here is the fix I received from support, a quick google search shows these IDs are not unique so they should work for anyone else having this problem:

1) Sign in to https://admin.google.com/ with your super administrator.

2) Click Main Menu (the Hamburger Button on the left side) > Security > API Controls > Manage Third-Party App Access > Configure an OAuth app > OAuth App Name or Client ID

3) Add two web applications with the following OAuth Client IDs:
101545705208641292657
76254656058-ue8d5fkuicrfjjhd8c1qngd2goaq3ngs.apps.googleusercontent.com

4) App access. The following access type will be applied to a client ID:
Select: Trusted: Can access all Google services

I'm having this issue as well, seems like a lot of hassle could be saved by adding these instructions to the KB or setup steps or else maybe just post the solution here so we can access it without waiting for a DM. But if you insist on a DM, send away.

Last reply almost a month ago, still no fix. We have several techs installing this software for our customers and so of course we created an SOP for how we manipulate this software to do what should be rather easy. Now I need to update the SOP to include editing config files by hand because the settings we need are no longer able to be configured in the web interface.
We setup 3 new customers and instead of doing incremental dailies the chained cloud backup did full backups daily which set off a flag on AWS almost immediately we were way over budget. Why the hell isn't this fixed yet?

On top of that if we need to tweak old plans the "<Schedule><Enabled>true" comes back but I'm not sure what that actually impacts, the gui remains the same if that's false or true.

Is there some published document regarding the xml entries that we can at least consult?
Massive thanks to JamesZ for taking the time to document a work around, you saved a customer for cloudberry because right now Veeam is looking real good if it wasn't for the massive hassle of changing everything.

Luckily already configured clients don't break as long as we don't touch the plan configs. But onboarding new setups is becoming more complex and wasting more of our time, Just unbreak whatever you broke it was working fine not too many versions back.