tag line

moving IT to the cloud with service not servers

Sunday, 22 July 2018

Login as A but send email as B

Operating your G Suite inbox on a separate domain to your logon address.

In a simple world a school would create a Google organization using the internet domain employed by the external website and public email and that would be the end of it. Unfortunately we don’t live in a simple world and the direct relationship between the email address and the user logon can often be altered by a change in circumstance

For instance, the school might be planning to consolidate under a standardised Trust or District logon as part of a rebranding exercise. Its also possible that the organisation was created using an domain than was less than ideal.  After all east-walthamstow-college-of-arts.co.uk is a great descriptor but tedious logon address.

Whatever the case most organizations are reluctant to give up an email address that is printed on stationary, external signage or embedded in software. So for a variety of reasons a school may require a different logon address to the one that routes mail.

In this example our fictional college wants to move to ewca.co.uk as the logon identifier for the long suffering students and staff but maintain east-walthamstow-college-of-arts.co.uk as the primary email address on all G Suite accounts. So how can this be achieved?


The first thing to understand is that in order to use ewca.co.uk for any purpose it must be registered within G Suite as a secondary domain. This process is fairly straightforward and is well documented by Google so there’s little point repeating it here.

Once the secondary domain is verified the G Suite  administrator has ability to upgrade each users primary address from student@east-walthamstow-college-of-arts.co.uk to student@ewca.co.uk. It’s a simple select and save action, Google takes care of all the backend housekeeping with a few advisory notes that are listed later.

As soon as the account is updated the user can logon as student@ewca.co.uk  while maintaining all the features and data of the original account. As a bonus the old student@east-walthamstow-college-of-arts.co.uk address is pinned to the account as an alias which allows the user to continue to receive mail.

Job done. Well not quite.

By default the primary (logon) address is the one that GMail uses when it  sends mail. Therefore although the user can receive mail on student@east-walthamstow-college-of-arts.co.uk
they are sending on  student@ewca.sch.uk which is not quite what we want.

Fortunately GMail has a way of fixing that.

In the 'Settings' dialog of the users GMail navigate to the 'Accounts' tab where you find the 'Send mail as' option.


Selecting 'Add another email address' allows the user to add the new alias as a send address after which it can be upgraded the new default (below).


Once that’s been done the account will send mail on the student@east-walthamstow-college-of-arts.co.uk address by default. The new address will be used to reply to mail regardless of the original send address.

This seems pretty straightforward but there’s an obvious problem. This is a user driven process, none of the actions can be controlled or managed from the admin console. Even allowing for a well informed student and staff body, publishing a crib-sheet for each user is going to lead to issues.

Mistyping the alias or failure to do anything at all will result in mail moving in unexpected directions. A manual process might be manageable for 100 users but not 1000+.

Faced with a problem like this the solution is always the same…  send for GAM.

GAM is a open source project that exposes the Google API’s as a simple command line interface that you can use to build batch files. It’s an essential component of every G Suite admins toolkit.

Fortunately GAM has a command for this, as it has for most functions.

gam user student sendas student@east-walthamstow-college-of-arts.co.uk "Student" replyto      student@east-walthamstow-college-of-arts.co.uk default treatasalias true 

It should be pretty clear how each of the elements in the command relate to the options in the user dialog show above.  Of course GAM can also help out with the first part  of the project, updating the users primary logon address using a command similar to that shown below.

gam update user student username student@ewca.co.uk

Therefore the process is reduced to running two GAM commands on each user account.
  • Change the users primary logon account to the new secondary domain.
  • Update the default send address to the email alias created by the first command.

Note: GAM provides methods to draw data from CSV files that will update 100’s of users in  single command .

For a large school it’s not recommended that to do this in the middle of the day. The process of renaming can take up to 10 minutes to propagate across all services and you must allow at least 24 hours for the directory to catch up. Like all major updates it should be handled using proper change control mechanisms and tested on a subset of users.

A couple of points worth noting.

The GMail user still has the ability to update the Send address by updating the configuration in the settings dialog. GAM will make change but it’s not locked down in any way. The more curious user can and probably will mess with this at some point.

Lastly, larger organisations may be using utilities such as Google Cloud Directory Sync to maintain G Suite user accounts which adds an additional degree of complexity. In this case the update to the primary user logon needs to be matched with a change in the synchronization rules otherwise you run the risk of creating duplicate accounts. Again it’s best to test on group of test users first.

Happy GAM’ing.

Saturday, 9 June 2018

Is your schools IT about to fall off a cliff?

This might be a UK phenomenon but about this time each year school IT admins start to give some thought to the summer IT upgrade.

This task is often approached with a degree of fear and trepidation and with good reason. In just under two decades IT has moved from being an interesting novelty to a core function for both administration and teaching. I’m not sure when the decision was made to compel schools to maintain an on-premise datacenter with a support network that wouldn’t shame a medium size business, but that's where we find ourselves today.

Finding the right skill set to support this complex on-premise setup is difficult. The level of technology found in schools is similar to what you would find in the commercial sector and includes server virtualization, shared storage, directory systems, wireless, tape backup and client management. Therefore education competes in the same salary space as businesses that are better placed to offer attractive deals to qualified support staff. A common response is to share resource or enter into a support contract with an external party but it’s often the case that this ongoing cost wasn’t allowed for when the shiny new boxes were first installed.

The other problem is that the “shiny new boxes” are no longer shiny or new. In fact they are now over five years old a replacement program is now on the agenda. Even if they’re still providing a reliable service they are likely to be out-of-support and warranty. If they go wrong who are you going to call. Ghostbusters are not going to help you here.  Extended support contracts can be a option but the costs are often in the the same ballpark as a replacement program.


The problem is often compounded by the fact that the equipment was purchased as part of the same initial investment  program and therefore all the hardware has come to the end of support at the same time. Servers are one problem but you may have a networked storage, tape backup systems and networking that are all facing the same issue.

Let's face it, your schools IT system is about to fall off a cliff.


There’s no simple answer to this problem. The short term solution might be to find the money to paper over the cracks but in a another five years time you’ll have same problem - nothing has changed.

The sustainable approach is to make use of Software and a Service (SaaS) and start to decommission local server and storage hardware. This is no longer a complex technical problem. There are plenty of  toolsets and partners who can help you out and the task is probably no more onerous than replacing core systems.

The major sticking point is the fact that the school will have to change the way uses IT and this will impact teaching. 

Software that has been part of the curriculum for the last 15 years will have to reassessed and alternatives found. Familiar desktop systems may have to be upgraded to modern mobile friendly versions. Workflows and lesson plans based on email attachments, local storage and printed worksheets will need to be reevaluated in light of a system that encourages, and in some respect requires collaborative practices.

This is the hard bit but can it be any harder than emptying the coffers to pay for on-premise system whose only promise is to deliver the same service as five years ago but with added cost and complexity.

Friday, 25 May 2018

Off Hours Device Profiles - A First Look.

The rumour that Google planned to support Off Hours device profiles for Chromebooks has been around for a while. An earlier post proposed how they might be used to support a Bring Your Own Chromebook (BYOC) policy for schools.

The basic idea was that a student could purchase a Chromebook and then use it in school operating under a security profile, only to revert back to a standard consumer device after 4 PM.  The benefits seemed to be obvious but the details were a bit vague because nine months ago scheduled device profiles didn’t exist - but they do now.

This post gives a brief description of how they work. As with most things Google it’s a simple idea that's been well implemented and the implications for future 1:1 programs could be significant.

The setting is found in the the Chromebook device area of the admin console in a new Off Hours policy.



The information required is pretty straightforward, the time zone for the schedule followed by a series of ON - OFF times.

In this example the policy is set to operate between 7:00 AM and 12:00 PM every Friday.

The dialog informs you that once set “some sign-in restrictions won’t apply”. The wording of the policy is a bit vague and the effect is not immediately obvious because, after saving the policy and rebooting, the Chromebook shows no change at all. Even though the policy should apply according to the time frame the user is still limited to organizational accounts only.

The change is only apparent after the organizational user logs on and then signs out which is a really nice feature. Effectively the Chromebook will only relax the security profile after being authenticated by a organisational account. Therefore if the Chromebook is left on the bus it’s not going to allow Guest Mode after 4 PM just because the policy applies at that time.

However after the organizational user signs in and out, it’s all change.

The organizational account requirement is lifted, guest mode is enabled and the user can log in with a standard consumer account.


Once logged in it's clear that the user session is set by a timer that's controlled by the Off Hours policy. In this case after 1 hour 50 minutes the session will terminate regardless of any internet access. Once the time is up it's goodbye Facebook and back to school for you !

So there you are, Off Hours device profiles. A very simple idea that provides a whole new way of putting Chromebooks into schools and no other client technology can do this.

Game changer is an overused term but in this case I'm not so sure.


Note: tested on a Chromebook running Beta V67.0.3396.57.