Integration with Google - Patrick

Login ID

Dedra

• IAM SC has final decision rights 
• Expected to be approved 
• Both services will use the same ID
• Dedra's team will represent this option to the committees
• Google has promised that email address for migrating parties will not change

• scoped CalNetID

If not approved, use current processes and separate IDs.   

McG: - or -use a (cloud) id that is used for all services that require an email address as a user's ID.

Authentication Mechanism

Dedra

• IAM SC has final decision rights 
• Will minimally require vetting through 3 different committees 
• Given former experience, expected to be approved 
• Will require an enforcement policy (dog suit) 
• We do not expect the final decision until after late February and will have to make decisions based on experience-to-date with committee
• Both services will follow the authentication rules contingent on whether they are high or low security services
• Dedra's team will represent this recomendation to the committees

• We will get the tenor of the committees at the end of February, and make decsions on provisioning process 
  
  

if not approved, build discrete provisioning process.  
McG: this will provide significant longer term support complications which will require rework.

Landing page - Description

Bill

• All PS services will have general and consistent service descriptions information posted on technology.berkeley.edu
  

• Describe all PS products on technology.berkeley.edu 
• Provide links to more detailed description pages

Support Strategies

Bill

• We will use a 5 tier support strategy as defined by SSC.  This is a longer term goal that we must converge on dependent on implementation strategies.* We will adopt consistent strategies - as far as possible - approaches, tools to provide support to end-users.  For deviations from a consistent approach, we should have a good reason.
• We will adopt the same support end-user entitlement policies across the services.
• We will adopt a hybrid support approach, that combines local departmental resources as tier 1 as an option to a fully shared tier 1 service desk.

We will adopt a consistent support strategy for PS services in the short term.

Each service will have its own approach which can be implemented more quickly, but probably result in greater confusion with the user population.  Movement to the shared service center will be complicated also by service-driven support approaches.

Tier 0 support

Bill

• All PS services will link to a Tier 0 support landing page on technology.berkeley.edu
• All PS services will use the same Tier 0 tools (listserves, knowledge bases, forums, social media??) to be extended to the user community.

Common tools and approaches will be adopted for services under the PS program.

• Link to FAQs and/or KB 
• Access to community tool 
• Links to social media??

Each service will have its own approach and toolset, which can be implemented more quickly, but probably result in greater confusion with the user population.

Tier 1 support

Bill

• Each team will link to Tier 1 support personnel/queues from the tier 0 page/s on technology.berkeley.edu
• Tier 1 will require ticketing systems
• Tier 1 resources will be shared in the longer term and cross trained.  
• Short term decisions will be made by each service on how to seed the tier-1 support function with skills.

• For Units with IT leads, link to departmental support persons/queues 
• For Units without IT leads, link to shared services center
  This approach requires separate landing pages based on the department (and perhaps within the department).

Tier 2&3 support

Bill

Definition of Tier 2&3 support will be driven by the Shared Service Center strategy.  Their approach is 

• Tier 2 will be service requests and Tier1 enabling functions.  
• Tier 3 will be break-fix and enhancement related.
• Tier 2 support will be likely performed by the shared service center, while Tier 3 will be provided by each service team of service specialists.   
• Common components or vendors used by each service will be addressed as Tier 4.

We will adopt a consistent support strategy for PS services in the short term.

Provisioning

Bill

• For new users of the "cloud package", provisioning will be driven by a user-centric approach which provisions multiple services from one provisioning page (with the same ID) on technology.berkeley.edu.
• For existing mail users, email will be migrated in phases over the next year or so.   
• Box provisioning will happen automatically, with the ID being the berkeley.edu email-address.  This decision needs to be made pronto!* Box will be self-provisioned from technology.berkeley.edu 
• GMail will be migrated and will not have self-provisioning. 
• New students can self provision Box from MyBerkeleyApps 
• MyBerkeleyApps has closed its development for Spring 
• There will NOT be a single, joint provisioning or invitation to provision from Box and GMail
• Where fo we request volunteers?

• A provisioning link for Box will be on technology.berkeley.edu and will redirect to box.berkeley.edu
• GMail will manually provision throughout its migration phases.  (I am unsure on this one?)

Migration/Rollout - Timing

Bill

• GMail is targeting a first phase migration for May 20
• Box's rollout dates are not dependent on Google's migration phases, but could be more closely aligned as part of PS in general.
• Box's critical path is designed around completion of provisioning 
• Box's rollout dates are dependent on release and testing of Box's new provisioning workflow + 5 weeks of local development; Box's provisioning software is due Feb 26

• These two services will not rollout at the same time
• GMail's migration is dependent around date
• Box will rollout in Q2
  

Migration/Rollout - Audience

Bill

• GMail is piloting through migration and are targeting current users
• Box and GMAIL will not target the same audience
• Box may choose a subset of students b/c they have less/no support needs and have little or no FERPA data

•  Target audiences TBD

Migration/Rollout - Tier 1 support

Bill

• Tier 1 resources will not be shared or cross-trained
• Box and GMail are both assessing hybrid support strategies (part shared service center, part unit IT leads)

• Box and GMail will approach shared services separately
• Box and GMail will approach unit IT leads separately

Deprovisioning

Bill

• Gmail and Box will not synchronize deprovisioning processes
• GMail and Box and GMail will create separate deprovisioning processes

• GMail will follow the current CalMail deprovisioning process
• Box will creates its own separate deprovisioning process

CalNet ID changes

Dedra

•  Given the interdependencies between the CalNetID and and account credentials, we will need a notification and update process for all effected services when CalNetId is changed

•  The timing on this can be in parallel bit should not slow down the authentication decisions

Security and Policy Training

Ann G

• SPP will develop Data Classification standards in conjunction with the Data Proprietors
• SPP will develop a campus-wide training curriculum on those data classification standards

• Leon Wong is developing the Data Classification system with Data Proprietors; this is expected to take 3-6 months
• Leon is developing interim definitions for Box's rollout
• Ann has verbally committed to the training curriculum in a Box meeting with Shel
• Ann has been reticent to own the training curriculum commitment since.

Terms and Conditions

User and Admin Guidelines