Architecture and operating model
Free/busy sharing queries availability for time intervals without carrying full meeting details. Same-tenant permission, external-organization sharing and Google Workspace–Microsoft 365 coexistence during migration are different flows. Define an incident by source tenant, target tenant, identity mapping and query direction rather than only by the user interface.
On Microsoft 365, organization relationships, sharing policies and federation or availability endpoints matter. On Google Workspace, Calendar Interop configuration, delegated service access and user mapping may apply. DNS Autodiscover, TLS trust and proxy reachability are prerequisites in some hybrid paths. Success in one direction does not prove the reverse direction.
Preserve the privacy boundary: free/busy-only access must not reveal subject, location or attendee details. Use least-privilege test identities and avoid logging calendar content. A source user × target user × direction × time-range matrix provides stronger evidence than random user tests.
- 1Source user and sharing policy
- 2Cross-organization availability query
- 3Target identity mapping and calendar read
- 4Free/busy response and privacy filter
Design parameters
- Sharing scope
- Map free/busy only, limited details or full details to policy and user permission.
- Identity mapping
- Validate primary address, alias, accepted domain and migration target account.
- Query direction
- Treat Workspace→M365 and M365→Workspace as independent acceptance tests.
- Time window
- Test long ranges, high item counts and time zones with controlled calendars.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Layer | Google Workspace | Microsoft 365 |
|---|---|---|
| Organization setting | Calendar Interop and sharing settings | Organization relationship and sharing policy |
| Identity/access | Delegated service identity and user mapping | Federation/availability access and accepted domain |
| First evidence | Admin setting, interop log and test-user result | Get-OrganizationRelationship and availability test |
Worked example
In a migration with 1,600 of 2,000 users on M365 and 400 remaining on Workspace, test at least four cells: within each platform and both cross-platform directions. Use two known busy blocks and one free block over the same seven-day range, recording alias and time zone.
If only 90-day requests fail while seven-day requests work, inspect window and item volume before changing authentication. Separate high-density calendars and client or service limits, such as a 1,000-item retrieval limit, from normal calendars.
Example commands: replace lab values and confirm permissions and software versions before use.
Get-OrganizationRelationship | Format-List Name,DomainNames,FreeBusyAccessEnabled,FreeBusyAccessLevel
Get-SharingPolicy | Format-List Name,Domains,Enabled
Get-AcceptedDomain | Format-Table Name,DomainName,DomainType
# Record a bidirectional test matrix; do not log real calendar content.Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| One direction works and the reverse fails | One reciprocal relationship or Calendar Interop direction may be missing. | Query the same pair both ways and compare organization settings. |
| Some users show unknown | Alias, accepted domain or migration target may map incorrectly. | Verify primary SMTP, aliases and the actual mailbox or calendar location. |
| Short range works, long range fails | Item volume, service limit or client timeout may apply. | Compare 7-, 30- and 90-day requests with duration and error code. |
Acceptance checks
- Create a separate test matrix for both directions.
- Verify only the approved detail level is returned.
- Check primary address and alias mapping for every pilot user.
- Export organization relationship and Calendar Interop settings.
- Validate DNS, TLS and proxy paths for hybrid endpoints.
- Record success rate and p95 duration for 7, 30 and 90 days.
Related concepts
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the account actually running the application, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
DNS caching and dependencies
DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.
TLS and certificate validation
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.