Google workspace - migrate primary domain as secondary domain to another workspace - google-workspace

I have not found clear documentation about this.
My company would like to migrate/move domain A in Google Workspace A to domain B in Google Workspace B.
We are also using Google cloud in both workspaces.
Since each Google workspace has a domain (A and B respectively) as a primary domain, we cannot remove domain A from its respective Google workspace, which is required for adding it as a secondary domain to Google workspace in domain B.
Merging 2 domains is possible, but it entails cancelling Google workspace/cloud identity on source domain A, if I understand correctly link.
It also involves saving Google workspace data, which takes days and needs to be tested.
There is also the question of whether users can still access Google resources such as cloud, while this transition is happening.
It is necessary to remove domain A from its workspace, before adding it to workspace of domain B. This means downtime, and I am unsure if Google cloud resources in domain A's workspace will be lost in transition.
Perhaps someone could shed light on the process.
I have researched documentation on Google about the migration.
There is a FAQ about multiple domains.

Related

"Blank tabs" on Teams App update deployment (Teams Toolkit)

My Teams app:
multi-tenant
deployed using Teams Toolkit to Azure Storage, CDN enabled with a Custom Domain
in alpha use by internationally distributed organisation (third party, not me), users around the world
the app functionality works fine including multi-tenant
in rapid development so frequent code updates. Very rare manifest updates.
Problem:
I frequently update the app's code and deploy the update to Azure using Teams Toolkit
when I do this users often report 'blank tabs' for a period of time, can be many hours. They see the tab menu but the tab contents are simply blank. Purging the CDN doesn't seem to help.
seems most common using Teams desktop app but also reported using browser and mobile Teams app
I think this may be an issue of code deployment .js files (each of which gets a new filename) not being available to the install, I can sometimes reproduce but very unreliably. Other times I can access the app, using a user account on the client's AAD, successfully from different locations (using a VPN to emulate location).
Previously the app's Custom Domain was managed on Cloudflare's proxy.
I disabled this and implemented Azure CDN.
Users continue to report the problem.
This is very poor user experience.
Does anyone have experience of this or hypotheses on what may be happening?
Thanks.
Would suggest to test one thing first: manually deploy a new code change to Azure storage, with the same storage-CDN-custom domain setup.
See if this also causes the hours delay symptom.
By doing this, if the issue is reproducible, it may indicate that the Azure Storage-CDN configuration needs to be optimized.
Otherwise please share the result and it will help narrow down the root causes.

Sharing TeamDrive with Contractors?

I am going to migrate onto Google Workspace. I will create several TeamDrives under there, where my contractors (photographer etc.) will upload the files they created.
They will use their own gmail account, not with an email of my company's domain.
In personal Google Drive, when someone shares a folder/file with me, those are still owned by them. Therefore, when they delete on their own personal account, those files are also removed from my side. As per my understanding, TeamDrive sorts out this issue. When they upload a file/folder into a TeamDrive using their own gmail account, the ownership of these are taken by the TeamDrive and protected from deletion in the future.
Can someone help me to clarify these questions?
Thanks
According to the documentation available about Shared Drives, which I think is the feature you are referring to, if a user outside of your organization contributes to your organization's shared drives, the content uploaded, created or edited is transferred to it and belongs to the shared drives uploaded.
The documentation says the following: "Any work an external user contributes (for example, edits to, creating, or uploading a file) is transferred to and owned by the domain that created the shared drive."
Here is the link in case you need it.
In addition, the external user shouldn't be able to remove the file unless the privilege given is Manager or Content Manager; to upload Contributor privilege is enough. Check the documentation about the access levels.
Google Shared Drive (former Team Drive) is suitable for transferring ownership of Google Drive files. Files on Google Shared Drive do not have an individual owner.
Another possible option is to use Google Forms to upload files to Google Drive. When using the apps script or Google Forms add-on, these files can be automatically renamed, organized into folders on Google Drive and Google Shared Drive.

Ops Hub User Matching

Can you please tell me where OPSHub Visual Studio Online Migration Utility pulls the user data from when doing a match, both on-prem and online? I am trying to match users for just one project, which has 41 users, however the utility wants me to match 119 users, many of which are not even associated with any project on my on-Prem TFS server. Additionally, where is the online user information pulled from? I have some that are displayed as email address, others seem to be usernames. Obviously I need to straighten this out so I can map to the correct users. Also, some users exist on Prem that will never map to any online user, so how can I get rid of them?
Project Collection Valid Users are pulled from both the end points. This is done to make the user mapping explicit. In some cases, a user might have done some changes in a project but is now no longer a part of the project. If such user is not mapped then, loss of information is observed when such data is migrated.
For users of on-prem who are not going to be in VSTS. You can map them as default to any other user. (Or maybe create a dedicated user for) Basically, all changes done by those users in your on-prem TFS would be shown as done by the user with which they would be mapped.

Packaged App: syncFileSystem / fileSystem API - For *large* files

I am looking to develop a Chrome Packaged App that will (at a very simple level) provide a dynamic form filling UI - but allow users to attach large attachments to the forms (could be upwards of 10 files of 10MB each). I would like to have the ability to save and share the form data and the attachment via Google Drive. The forms will be completed collaboratively by multiple team members who also need to all see the attachments. Imagine a form front-end/metadata that sits on top of a shared Google Drive folder...
I have read the documentation, and learnt that the syncFileSystem API is not intended for use for general and/or large files to be stored in Google Drive, but rather for small configuration data.
I then looked at the fileSytem API - hoping that I could include the Sandboxed folder for the app in the folders that the Google Drive Client App (so that the files get synced automatically) - but it doesn't look like the sandbox is meant to be accessed externally.
My current thinking is to recreate a windows explorer type UI in the packaged app (can use drag and drop) - then store the files in the sandbox using the fileSystem API. I can reuse the code from the Google Drive sample packaged app to implement cloud syncing. Good idea?
Two questions stem from this:
How persistent is the fileSystem API. The documentation mentions that the user can purge all stored files - is this done through 'clearing all browser history' ? In which case they could very easily accidentally wipe many hundreds of MB of useful information that I am storing in the packaged app.
I have read that you can use a 3rd party authentication services (which I want to do). If I use a non-Google account to authenticate my users, how would the Google Drive authentication work ? Would I be able to use a different Google account to perform the cloud storage (i.e. unrelated to the actual end user, who may or may not have a Google account already - which may already be signed in)
It seems like waiting for this https://code.google.com/p/chromium/issues/detail?id=148486 (getting read access to non-sandbox directories) would be the easiest way forward.
I don't think clearing browser history deletes temporary sandbox filesystem files, they're supposed to be sort of automatically garbage collected when space is required. It would make sense if that were another checkbox in the "Clear browsing data" section of chrome's options. Perhaps that would make the answer to your first question more clear :-)
The second point, I am not sure how to do this, but it looks like you have already figured out something? At least that's what this page https://groups.google.com/a/chromium.org/forum/#!topic/chromium-apps/hOYu75Cv0AE seems to indicate

Using a CNAME with Shared Windows Azure Website

I've been following instructions on the Azure site to add a CNAME to point to my Azure website. I have had some problems getting it to work and there seems to be some contradictory information in some of the posts.
I have my website running in "Shared" mode, which according to the Azure instructions supports custom domains and indeed it seems to allow me to manage domains. But some posts seem to indicate that I have to run in reserved mode. Can anyone confirm this?
Also, some posts seem to indicate that I need to add the CNAME in the Azure management portal, but I cannot find where this is. Any help appreciated?
I don't really understand A records and CNAME that well. My DNS provider allows me to add both. Do I need to change both? Currently my A record points the "root" to the IP address that Azure gives me and the CNAME points www.mydomain to the Azure website host mysite.azurewebsites.net. I have left them for a while to propogate and nothing seem to happen.
The notion of FREE, SHARED, RESERVED website categories are very recent; Microsoft Launched it just 2 days ago. Earlier it used to be either FREE or RESERVED. You get to attach a custom domain name only for reserved instance.
With the new feature of low cost shared option, you get to attach a custom domain but it will still be in the shared pool of Azure Websites. It works out around $9.36 a month.
The reason for contradiction info in the posts are due to new to features. In short you can use both SHARED and RESERVED for attaching custom domain. With shared it is little cheaper provided you are fine with your website being served for shared pool.
Just go the SCALE Table and make your website instance SHARED from default free and then go to Configure table to put your CNAME
DNS Management is handled differently by different domain or hosting providers , there are three places these changes can be performed (may be more )
cpanel
domain manage panel
WHM panel
if you have only taken a domain most probably your domain provider will send you a url, in which "manage dns " option will be there.
if your site is already hosted then you might have to do it in cpanel or whm.
so better call your domain hosting provider for exact steps . it saves a lot of time