Black Cat Security

Check when your Google Meet meeting codes expire to ensure smooth future meeting experiences

Quick launch summary

Google Meet meetings can be scheduled across Google Workspace products, such as Calendar, Gmail, Google Chat, and more. This means your unique meeting code and its expiration are based on the product that your meeting is created from.
Most meeting codes will expire 365 days after the last use, but there are instances where the meeting code will expire instantly once the meeting ends. See below for a complete breakdown of meeting code expirations according to the product they were generated by. These meeting code expirations will take effect beginning May 19, 2021.

We strongly recommend you use the table below to ensure your meeting codes are valid, especially for meetings you plan far in advance.
Where the meeting is Generated How long the meeting code is valid
Google Calendar

Meeting codes expire when the following two conditions are met:

1) The meeting code has not been used for 365 days, and

2) The meeting code isn’t associated with any future calendar events.

Note: If a code is created in another product and pasted in a Calendar invite, the code will expire according to the product it was generated from.

Gmail and the Google Meet homepage Meeting codes expire 365 days after last use.
Google Chat and Google Hangouts Meeting codes expire 365 days after last use.
Breakout Rooms Breakout rooms expire instantly once the parent meeting ends.
Jamboard and Meeting room hardware Meeting code expires instantly once all users leave the meeting.
Nicknamed meetings

Note: Available to Google Workspace subscribers only.
Meeting code expires instantly once all users leave the meeting.
Google Classroom Meeting code expires instantly once all users leave the meeting.
Other Third Party Applications Meeting codes expire 365 days after last use. If someone uses the code within the 365 day window, then it will add another 365 days to the shelf life.
Google Nest

Meeting code generated by speaking into your Nest device and saying “Hey, Google start a meeting” expires 365 days after last use.

For users in the Google Workspace with Google Assistant Beta: Meeting generated by usage of meeting nicknames, expire instantly after the last user leaves.

Getting started

  • Admins and end users: We recommend reviewing the meeting code expiry limits to ensure your meeting codes are valid, especially for meetings planned far in advance.

Rollout pace

Availability

  • Available to all Google Workspace customers, as well as G Suite Basic and Business customers
  • Available to users with personal Google Accounts

Additional tools for managing the transition from classic to new Google Sites

What’s changing 

In 2017, we announced that we would replace classic Sites with new Sites, and in 2019 we announced that domains will have until the end of 2021 to complete the transition. Important note: Starting May 15, 2021, website creation in classic Google Sites will no longer be available. Visit the Help Center for more details on the Classic Sites migration. 
To help Admins and end users manage the transition to new Sites, we introduced the Classic Sites Manager in 2020. Recently, we’ve added several new options to the Classic Sites Manager to help you and your users manage the transition from classic Sites: 
  • Super Admins can now delegate admin-level Classic Sites Manager access to other users in their organization via a new assignable privilege, allowing them to do things like assign site owners or convert websites to the new Google Sites experience on behalf of their end users 
  • Admins and site owners can now bulk delete and restore sites within the Classic Sites Manager 
  • Admins can now bulk update ownership of sites from within the Classic Sites Manager 
See below for more information. 

Who’s impacted 

Admins and end users 

Why it’s important 

We hope these new options help admins and their end users navigate the transition from classic Sites to new Sites. 
Admins can delegate admin-level access to the Classic Sites Manager to the right people within their organization, allowing them to view all classic Sites and determine which migration actions need to be taken (convert, delete, assign site owners, etc.). 
With the addition of the delete bulk action in the Classic Sites Manager, admins (or delegated admins) can quickly remove any sites that are no longer relevant within their domain. End users will be able to remove any sites they own. Once a site is deleted, a user or admin has 30 days to restore it before it is permanently deleted. 
For sites that have no owners, admins (or delegated admins) can now use the update owners action to assign ownership of sites to a point of contact in your organization who can best advise on whether the site should be deleted or converted to new Sites. 
Additionally, sites can be converted to the new Sites experience using the Classic Sites Manager, with the option to export a filtered view from the Classic Sites Manager to Google Sheets for record keeping or further analysis. 
The Classic Sites Manager can be used to convert, delete, restore, and assign ownership of sites within your domain.

Getting started 

Rollout pace 

Availability 

  • Available to Google Workspace Essentials, Business Starter, Business Standard, Business Plus, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Fundamentals, Education Plus, and Nonprofits, as well as G Suite Basic and Business customers 
  • Not available to Google Workspace Frontline customers 

Resources 

New – Create Microsoft SQL Server Instances of Amazon RDS on AWS Outposts

Last year, we announced Amazon Relational Database Service (Amazon RDS) on AWS Outposts, which allows you to deploy fully managed database instances in your on-premises environments. AWS Outposts is a fully managed service that extends AWS infrastructure, AWS services, APIs, and tools to virtually any datacenter, co-location space, or on-premises facility for a truly consistent hybrid experience.

You can deploy Amazon RDS on Outposts to set up, operate, and scale MySQL and PostgreSQL relational databases on premises, just as you would in the cloud. Amazon RDS on Outposts provides cost-efficient and resizable capacity for on-premises databases and automates time-consuming administrative tasks, including infrastructure provisioning, database setup, patching, and backups, so you can focus on your applications.

Today, I am happy to announce support for Microsoft SQL Server on Outposts as a new database engine. You can deploy SQL Server on Outposts for low latency workloads that need to be run in close proximity to your on-premises data and applications. All operations that are currently supported for MySQL and PostgreSQL on RDS on Outposts can be performed with RDS for SQL Server on Outposts.

Creating a SQL Server Instance on Outposts
To get started with Amazon RDS for SQL Server on Outposts, in the Amazon RDS console, choose Create Database. Use the AWS Region that serves as home base for your Outpost.

Creating a SQL Server instance is similar to creating a MySQL or PostgreSQL database engine on Outposts. For Database location, choose On-premises. For On-premises creation method, choose RDS on Outposts, as shown here:

In Engine options, for Engine type, choose Microsoft SQL Server, and then choose your edition (SQL Server Enterprise Edition, Standard Edition, or Web Edition) and version. The latest available minor version of each major release, from SQL Server 2016, 2017 up to the newest, which is 2019. There are plans to add more editions and versions based on your feedback.

RDS for SQL Server on Outposts supports the license-included licensing model. You do not need separately purchase Microsoft SQL Server licenses. The license included pricing is inclusive of software and Amazon RDS management capabilities.

In DB instance class, choose the size of the instance. You can select between Standard classes (db.m5) or Memory Optimized classes (db.r5) for SQL Server.

The process for configuring an Amazon Virtual Private Cloud  (Amazon VPC) subnet for your Outpost, database credentials, and the desired amount of SSD storage is same as creating RDS instances. When everything is ready to go, choose Create database. The stat of your instance starts out as Creating and transitions to Available when your DB instance is ready:

After the DB instance is ready, you simply run a test query to use the new endpoint:

Now Available
Amazon RDS for Microsoft SQL Server on AWS Outposts is now available on your Outpost today. When you use Amazon RDS on Outposts, as with Amazon RDS, you pay only for what you use. There is no minimum fee. For more information, see the RDS on Outposts pricing page.

To learn more, see the product page and Working with Amazon RDS on AWS Outposts in the Amazon RDS User Guide. Please send us feedback either in the AWS forum for Amazon RDS or through your usual AWS support contacts.

Learn more about Amazon RDS for SQL Server on Outposts and get started today.

Channy

Google Device Policy app ending support for iOS 11 soon

Quick launch summary 

The Google Device Policy app won’t support mobile devices running iOS version 11 or lower after August 2021. If your organization has advanced mobile device management (MDM) enabled, users must upgrade to iOS version 12 or higher to access new MDM features or to download the Device Policy app for the first time. 
We will remove support for iOS 11 in the first release of the Device Policy app beginning September 2021. Therefore please ensure your users upgrade their devices by the end of August 2021 to avoid any disruption to their work. 
Use our Help Center to find more information on minimum device requirements for Google mobile management.

Google Docs will now use canvas based rendering: this may impact some Chrome extensions

Update

[May 26, 2021]: We’ve updated the “Additional details” section of this post with more information on Google Docs accessibility features and support. Please see below for more information.

What’s changing 

We’re updating the way Google Docs renders documents. Over the course of the next several months, we’ll be migrating the underlying technical implementation of Docs from the current HTML-based rendering approach to a canvas-based approach to improve performance and improve consistency in how content appears across different platforms. 
We don’t expect this change to impact the functionality of the features in Docs. However, this may impact some Chrome extensions, where they may no longer work as intended. 

Who’s impacted 

Admins and developers 

Why it’s important 

Some Chrome extensions rely on the way the backend of a Google Doc is structured or specific bits of HTML to function properly. By moving away from HTML-based rendering to a canvas-based rendering, some Chrome extensions may not function as intended on docs.google.com and may need to be updated. 
Admins should review the current extensions deployed in their organization. See this file for an example of a Google Doc using canvas-based rendering and to test out your extensions.
If you are building your own integrations with Google Docs, we recommend using Google Workspace Add-ons framework, which uses the supported Workspace APIs and integration points. This will help ensure there will be less work in the future to support periodic UI implementation changes to Docs. 
If your company has developed a private Chrome Extension that you believe will be impacted and you are unable to migrate to the Google Workspace Add-ons framework, you can submit this form to provide feedback and notify our team

Additional details

Compatibility for supported assistive technologies such as screen readers, braille devices, and screen magnification features, will not be impacted by the canvas-based rendering change. We will continue to ensure assistive technology is supported, and work on additional accessibility improvements enabled by canvas-based rendering.

Getting started 

  • Admins and developers: 
    • To see an example of a Google Doc using canvas-based rendering, please see this example file. We strongly recommend reviewing the current extensions used in Google Docs that are deployed within your organization.
    • To ensure any Chrome extensions you build in-house continue to work as intended, we recommend migrating them to the Google Workspace Add-ons framework
  • End users: No action required. 

Rollout pace 

  • Google Docs will be migrating slowly from HTML to canvas based rendering over the course of the next several months. 

Resources