Lab walkthrough: configuring services for a department

The last session is a rehearsal for February. Jules Baptiste's e-commerce team, 18 people who run the online shop at birchline.example, will move to Workspace with the rest of head office, and Jules has asked to go first within the wave, because the team works closely with outside agencies and wants a week to settle in before the busy spring season. Sofia asks Owen to plan the whole configuration for the team and rehearse it with test accounts in the /Pilot OU, using everything from the course. "Pretend it's February," she says, "but do it now, while mistakes are cheap." This lesson follows his walkthrough from fact sheet to change log.

Step 1: Gather the facts

As in the first course's onboarding lab, Owen starts with a fact sheet, because every later decision depends on it.

Step 2: Mail

The team's mail flow follows lesson 1. Until the head office wave, Exchange stays primary; the 18 users get forwarding to the routing subdomain g.birchline.example when their wave moves, and Gmail's outbound route to Exchange carries mail to colleagues who have not moved. The two shared addresses are already Google groups from the first course, with Collaborative Inbox turned on for orders-help@, so customer service can assign messages.

The rules the team needs are mostly inherited: the card number quarantine for /Head office and the executable attachment rejection at the top level. Owen adds one rule for /Head office/E-commerce: inbound messages to orders-help@ from the platform's notification address get a header, so the team's filters can separate automatic platform alerts from customer messages. He tests it with the platform's sandbox, which sends real-looking alerts to a test address.

Step 3: Authentication for the platform

Order confirmations are the most important mail the company sends, because customers need them and phishers imitate them. The platform sends them from its own servers with From: orders@birchline.example. Following lesson 2, Owen checks the DMARC aggregate reports: the confirmations pass SPF through the platform's include but have no birchline.example DKIM signature. He asks the platform vendor for a DKIM key with the selector shop1, publishes the vendor's public key at shop1._domainkey.birchline.example and confirms in the reports two days later that the confirmations now pass DMARC with aligned DKIM. That removes the biggest obstacle to moving the DMARC policy to quarantine later.

Step 4: Safety

E-commerce receives many messages from strangers: customers, marketplaces, people offering partnerships. The safety settings stay at the head office defaults from lesson 3, warning banners for spoofed employee names and spam for lookalike domains, with one addition: Jules asks for enhanced pre-delivery scanning on orders-help@, which receives attachments from customers. The short delay does not matter for customer service, so Owen turns it on for the configuration group that holds the customer service group's members.

Step 5: Calendar

The team books two rooms on floor 3, which will exist as Google resources after the February room cutover (lesson 4). Owen checks their names, capacities and video features in the resource upload file, and confirms that the boardroom remains bookable only by assistants, so Jules's quarterly reviews go through an assistant. The platform developers need to see the team's release calendar; Owen creates it as a secondary calendar owned by the role account ecommerce-ops@birchline.example and shares free/busy with the developers and full details internally.

Step 6: Drive and sharing

The E-commerce shared drive and its roles come from lesson 5: Jules and an IT administrator as managers, the product owners as content managers, the team as contributors. With 96,000 items, one shared drive is enough. The release notes folder is the sharing question. The developer firm uses Google Workspace on devworks.example, which is not on the allowlist, so Owen has two options from lesson 6: add devworks.example to the allowlist for head office, or keep the release notes in a separate small shared drive with the two developers as external members. He chooses the separate shared drive, E-commerce releases, because only two people at one firm need access and the allowlist would open sharing with that firm to all of head office.

Before the move, Jules runs the search for files on the old share that were shared outside or with everyone, as lesson 6 recommended. It finds 14 files with old public links to product images, all intended for an agency that has since been replaced. They are not migrated with public links.

Step 7: Meet, Chat and the agencies

Meet needs nothing new: head office defaults allow outside participants to request to join, and the team's sprint reviews with the developers are recorded to the E-commerce releases shared drive. For Chat, Owen creates an external space, E-commerce and DevWorks, with the two developers, which needs external chat for the team. Head office allows external chat only with allowlisted domains, and devworks.example is not one, so he allows external chat for a configuration group cfg-ecommerce-external that holds the team, rather than changing the whole OU. The space is labeled External, and the team agrees not to post customer data in it.

Step 8: Other apps and Gemini

The team needs Forms for a release request form, already on for head office, and AppSheet for one product owner who builds a stock-check app, which means adding her to cfg-appsheet-builders after training (lesson 8). Gemini comes with stage 2 of the rollout: the team's group joins cfg-gemini-early, which turns on Gemini feature access and the Gemini app for them, while the OU setting stays off (lesson 9). Owen adds a line to the team's welcome message linking to the usage guidelines.

Step 9: Apps and API access

DiagramDesk is already trusted for head office from lesson 10's review. NoteForge, the test-management tool, has never been reviewed and requests full Drive access. Under the unconfigured apps rule, the team cannot connect it until it is reviewed, so Owen asks the vendor about narrower scopes; the vendor offers a mode that needs only access to files created with the app. Teresa approves NoteForge with specific Google data access for that scope, for the E-commerce configuration group only, and it goes into the integration register.

Step 10: Check the configuration against the plan

With the settings applied to the test accounts in /Pilot, Owen checks that what the console shows matches what he planned, using the values he recorded from each settings page during testing. A comparison catches the setting that was saved in the wrong OU or the toggle that never saved.

planned = {
    "Gmail: orders-help header rule": "on",
    "DKIM selector shop1": "passing",
    "Enhanced pre-delivery scanning (customer service)": "on",
    "Shared drive E-commerce releases: external members": "allowed",
    "External chat for cfg-ecommerce-external": "allowlisted plus devworks.example space",
    "Gemini feature access for cfg-gemini-early": "on",
    "NoteForge access": "specific Google data",
}
observed = {
    "Gmail: orders-help header rule": "on",
    "DKIM selector shop1": "passing",
    "Enhanced pre-delivery scanning (customer service)": "off",
    "Shared drive E-commerce releases: external members": "allowed",
    "External chat for cfg-ecommerce-external": "allowlisted plus devworks.example space",
    "Gemini feature access for cfg-gemini-early": "on",
    "NoteForge access": "blocked",
}
mismatches = [k for k in planned if observed.get(k) != planned[k]]
for k in mismatches:
    print(f"MISMATCH  {k}: planned {planned[k]!r}, found {observed.get(k)!r}")
print(f"{len(planned) - len(mismatches)} of {len(planned)} settings match the plan")

MISMATCH  Enhanced pre-delivery scanning (customer service): planned 'on', found 'off'
MISMATCH  NoteForge access: planned 'specific Google data', found 'blocked'
5 of 7 settings match the plan

Two settings do not match. Enhanced pre-delivery scanning is off because Owen selected the configuration group, switched the setting on and moved to another page without saving, so the change never took effect. NoteForge shows as blocked because Teresa's approval was recorded in the register but nobody changed its access level in API controls. Both are fixed in minutes, and both are exactly the kind of error that would otherwise surface as a help desk ticket on the team's first morning.

Step 11: Change log and rollback

Each change goes into the change log from lesson 11, classified and with its rollback. Most are normal changes tested in /Pilot. The external chat configuration group and the new shared drive with external members are reviewed by Teresa because they open new routes outside the organization. The DKIM key for shop1 has a rollback of removing the record and asking the vendor to stop signing, which would only be needed if the vendor's signing broke.

Step 12: What the team sees

The last step is communication. Jules's team gets a one-page welcome: their mail and the shared addresses, how to find the rooms, where the shared drives are and which one the developers can see, the external Chat space and what not to post there, the Gemini usage guidelines, and how to ask for a new app. Owen schedules a 30-minute walkthrough on their first morning and a check-in at the end of the first week, when he will look at the help desk tickets, the admin log for unexpected changes and the reports for sharing activity.

Sofia reviews the plan and changes one thing: the external chat configuration group should expire. She asks Owen to add a review date in three months, when the developer firm's contract is due for renewal, because temporary access that nobody reviews becomes permanent access.