Client Services is currently slated to move to exchange online on Monday afternoon. This is for all of our staff/student accounts internally, not “everyone that Client Services supports”.
The mailbox migration is fairly low-impact for users. The most common issues seen when moving to Exchange Online are as follows:
Mobile devices: Mail on mobile devices will typically need to be set up again (remove and re-add the exchange account). Make sure to enter the username as: email@example.com. Domain\username will not work.
Calendar delegation: Delegates may not be able to manage a migrated person’s calendar until they too are migrated to Exchange Online. It is for this reason that users will be moved together by department, but many delegation grants cross department lines.
For any issues we cannot resolve ourselves, please rope in Ben or Keenan directly.
As part of the Exchange Online project, one additional hurdle that has come up is that the ONID Namespace requirements (1 – 8 characters, letters and numbers only) will also need to apply to non-ONID domains. This means that we’re going to need to rename all of our student employee accounts so that they’re distinct from regular ONID accounts, as well as our administrative accounts.
Moving forward, student employee accounts will have a naming standard of se-[onid username]. Our administrative accounts will be changing to wa-[onid username] (workstation admin).
As of ~4:30pm today, Java is no longer part of the default MDT task sequence for CN builds. If a user does need Java installed, that will have to be done by hand during the build process, done during placement, or addressed over the phone. Existing Java installs will still be automatically updated as appropriate.
The most common instances where Java will be needed are:
Banner Workflow Modeler
Banner Relationship Modeler
Please note that Banner 9 does notrequire Java to be installed, and will be the only Banner option after the 31st of this month.
Starting this evening, we’ll be rolling out a new BITS policy. BITS (Background Intelligent Transfer Service) is the Windows feature that controls background downloads such as Windows or Office Updates.
This updated policy will be replacing a 10+ year old policy, with the key difference being that we’ll be enabling local subnet peer to peer traffic to reduce overall bandwidth requirements for external sites. This evening (11/8) we’ll be rolling out the new policy to AES sites, and assuming no issues result, Extension sites a week from today (11/15). The master ticket for this change (along with more technical specifics) can be found here.
As a reminder, a general overview of all our fleet wide group policies can be found here.
The Microsoft Bitlocker Administration and Monitoring (MBAM) policy for machines in the CN domain has been updated to not require a PIN by default. This has no impact on existing MBAM configurations (e.g. it isn’t going to clear out the existing PIN), but it does mean that an existing install with a PIN can be changed to a blank PIN.
As a reminder, a general overview of all our fleetwide group policy objects is available here
Reminder: a brief overview of fleetwide policies is available here.
As of 5pm on 9/25, we’ll be changing the way our local admin GPO functions. Currently, the GPO attempts to do the following:
Create/set the local Support account (This fails 100% of the time and just generates event log entries)
Create/set the local SupportRemote account (This fails 100% of the time and just generates event log entries)
Add the local Support account to the local administrators group
Add the local SupportRemote account to the local administrators group
Add the CN\Desktop Admins group (our network admin accounts) to the local administrators group
After the change, a new policy (Windows – Local Administrators) will do the following:
Add the local Support account to the local administrators group
Add the CN\Desktop Admins group to the local administrators group
Remove the local SupportRemote account from the local administrators group
The local Support/SupportRemote accounts are created as part of the build process, so they don’t need to be created via policy.
The important change is that after a machine processes this new policy, SupportRemote will not be an admin on machines. This is a good thing as we typically give out the password to anyone who asks (or as part of normal troubleshooting), and we really don’t want to be inadvertently giving out admin credentials to the fleet.
If customers call in looking for help because they were expecting to use SupportRemote as an admin account, we should help them get a regular Lastname_F local admin account set up. (See this KB article for details).
If a customer was using the SupportRemote account to manage multiple machines, chat with Ben about getting a network user plus account spun up for them.
The default domain for machines joined to the CN domain has been set to ONID. This has been done because the vast majority of our customer user accounts are in the ONID domain, so this will save folks from having to remember to put “ONID\” when logging in to a new machine.
Conversely, folks who do need to log in with CN domain accounts (service accounts, student workers, authenticating with “user plus” accounts) will now need to remember to put “CN\” in the username.
Mozilla released the next major version of Firefox ESR (Extended Support Release), which has some notable implications. I would expect the fleet to be mostly updated to FF60 ESR any time between “now” and a week-ish from now.
For the major changes:
NPAPI support has (finally) been removed, in line with every other major browser. This means plugins such as Java, Silverlight, etc cannot be run in Firefox. A message went out to Banner users on Monday of this week informing them that the recommended web browsers are IE (Windows) and Safari (macOS) as of today.
If folks are noticing that the browser seems dramatically snappier, they’re right! Firefox ESR now uses the updated multi-threaded rendering engine (Branded as “Quantum” and originally rolled out in Firefox 57).
Updated addon system. With the multi-threaded rendering engine, a side effect is existing addons (e.g. uBlock Origin, NoScript, etc) have to be rewritten. For many addons they’ve already been rewritten — FF57 rolled out back in November and changes were communicated to addon authors 6-12+ months prior to that. In some cases addons have not been rewritten due to authors abandoning them, or because the new addon system does not permit what it was trying to do. For those addons there’s not much to be done other than looking for a compatible addon that replicates the functionality if possible.
There are “forked” versions from older Firefox builds that still support NPAPI plugins and the legacy addon system – please do not install these for customers as they also tend to be significantly behind on security updates.
If a customer is running the “non-ESR” version of Firefox, this is all old news as these changes happened in November.
Langton hall will be moving to the new core network this evening. This is a relatively small migration (around 40 hosts and three printers), covering Kidspirit and BPHS. After the move, hosts for either department should end up in the CN_IRS or CN_Printers container, in the “Small buildings” site (this “site” covers buildings not large enough to have their own switch). More details are available in the TD ticket, #2683198.