Email and Calendaring SLA

Hi Rooney,
Thanks to you and everyone else for their questions and thoughtful suggestions on this. I’ll try to answer each one below beginning with “IT Response” so we can keep track.

– Should title of SLA be “O365 Services” or similar? Email and calendaring does not fully encompass all of the services available in O365 unless there will be separate SLAs for IM and OneDrive for Business.
IT Response: We actually debated this several times both in the SLA meetings and in many Service Catalog meetings related to this. I think at some point we may need to collapse these, but initially we wanted to treat email and calendaring separately given the significant reliance on the service, time constraints, the need to focus on email service specifics, and the desire to keep the SLA to a manageable size. But good to hear that you and others are with us in thinking about these services as related.

2.1.1.1:
– Is the baseline level of service departments are expected to provide the material provided in the FastInfo documentation?
IT Response: Yes, but there may be internal Fastinfo answers used for triage and troubleshooting that might be shared as well.

– IT Agent participation is at Banner Level 3 org. A Level 3 org can have multiple representatives, but that requires approval by the CIO per http://cio.unm.edu/agents/role.html. Should language be adjusted to reflect end-users or departmental IT working with their Level 3 rep?
IT Response: This is a good point and personally I didn’t remember this about the Agent role—I think your suggestion is a good one.

– Should there be different bullet points depending on the type of support relationship the department has with UNM IT? Some departments have Tier 2 support and some do not?
IT Response: Possibly, if I understand you right that might help to delineate further what we’re getting at there. I’m told there was a great discussion at IT agents regarding how to appropriately reference IT support provided by departments. The agreements committee is looking at this issue from the perspective of standard language in the SLAs, at least as a starting point. We will forward this suggestion to that group.

– Should self-service docs also be added as an end-user responsibility in 2.1.1.2?
IT Response: Good catch: we had it there at one point and it fell out in one iteration or another. Thanks!

2.1.1.2:
– Seems like users checking email and frequency is out of scope for SLA and not something UNM IT (or any IT dept) should have to worry about. That is an HR and employee performance issue?
IT Response: We wondered about that as well and had added it in relation to the Student policy that has language to that effect and the related boundary in 2.1.2 regarding forwarding. We tend to agree and will reconsider this point.

– Should this also be a requirement of departmental IT? Business-related communications and information should not be forwarded off site and we will not assist folks forwarding emails to non-UNM accounts?
IT Response: That’s a great suggestion as well—that helps us address the fact that we don’t have an official UNM Policy on Employee use of email and at least puts all of us (UNM IT and Dept IT) in alignment on that issue.

2.1.2:
– Are there specific timelines that can be included in the SLA for this separation process and when work-product/email disappears? Same timelines as those listed in NetID SLA?
IT Response: Great idea. And yes, they are more or less the same timelines that follow the NetID, but with a few specific notes on email. So this could refer to the other SLA/Service and add additional information.

– For bullet item 4, should that also include personal, non-UNM devices? Is setting up the Outlook client on my home PC or personal smartphone akin to forwarding sensitive emails to non-UNM accounts?
IT Response: That’s a really great question, and it might be more than one question! That is, I hear both a support question and a security question in there. Either way, it breaks down across student/employee lines, of course, since at one end of the spectrum our core users don’t have anything *but* personal devices. However, with both questions with regard to employees are a different matter, and we should give those points additional thought. Were you suggesting we say something along the lines of “Support is not available to employees for personal devices”?

– Is it appropriate to provide a time line for provisioning of service when an employee starts?
IT Response: Could be, and makes sense to include that as related to the first item about de-provisioning. Again—basically the same as NetID, but with specifics to email.

– Are instant messages (IMs) treated the same as emails with respect to retention?
IT Response: Yes—IF you have Skype for Business saving your conversation history. We are not retaining those outside the user-driven settings.

Posting for Steve Spence: Good point, Dann, we will add the appropriate language and point to the fast info article https://unm.custhelp.com/app/answers/detail/a_id/6672/ . It is now a self-service function. We don’t have the ability to restore beyond the information listed in the article.

Hi Cyndi. Thanks for bringing this up. I’ve moved the topic to the process section as it likely applies to many different SLAs. Please see my thoughts there: http://discuss.unm.edu/document/department-specific-sla/.

Posting for Steve Spence:
SLA for OneDrive – Andrew, see the response I gave earlier to Rooney’s similar question. We’re considering OneDrive a separate service at this point so we’ll likely have a separate SLA for that eventually.
Fees – Good point: I think that line was boilerplate and we didn’t edit it specific to this service. It’s generic and covers it even if there is no fee.
IE Limitation – The limitation on IE has been removed from A to Z. It now states “Directory listing is accessible by current vendor supported browsers delivered with the OS (operating system).”
MyUNM vs. direct access – Good – we will adjust.
“Intentionally” – If and when we can identify the appropriate controls to prevent this from happening, we would like to do it. As it stands we are making a best effort to avoid sending links that require authentication in official communications but are also reliant on educating end users to never act on such requests.
Available Reports – Thanks! We will pass that on the Agreements committee.

Posting for Steve Spence: The online archiving feature in Exchange can be expanded for a fee, but we don’t have the mechanism set up to take advantage of that yet, so we won’t put it in the SLA for now. We will at some point in the future. This is pretty similar to other providers. In terms of the multiple methods, it depends on how your users are supported today and what local archives they have deployed (be it Thunderbird, MacMail, Outlook, etc.). In any case those are already stored locally and those can remain right where they are.

Posting for Steve Spence: Great point—we agree and have seen other schools allow students to keep their original email address “for life,” and we have the option of doing that in our current system. There are discussions to that effect, but no firm decision has been made. The Alumni Association does have a forwarding service, but it’s not related to your original email address. In any case, it’s a matter of coordinating that policy with them and other areas to make it true across the board. At the same time, there might be ways of addressing it by using guest ID status for departments that wanted to maintain them.

Posting for Steve Spence: If those archives are in PST format they should be able to be preserved as-is. But if they are “online” archives, we’ll have to discuss options for migrating or maintaining them long term and determine an agreement on how those will be handled.

Posting for Steve Spence: I’m assuming you mean they aren’t enough… Actually both of these are now adjustable, but the additional online storage comes with a per-user cost. We only just became aware of the message-size configuration options and are evaluating options and impact, so I don’t think we can include them in this iteration of the SLA.

Posting for Steve Spence:
Microsoft BAA – This means (generally) that Microsoft’s offerings are technically able to be compliant with the information types identified in the BAA; however, there are two elements that always need to be enforced in addition to any vendor BAA – that the institutions operational controls are defined, in place, and enforced, and that the appropriate technical controls are defined, in place, and enforced. While Microsoft’s solutions can meet technically meet those requirements defined in the BAA, UNM’s Data Owners are working with the Information Security and Privacy Office (ISPO) to clarify and codify the technical and operational controls. At the current time, the process is to request approval and authorization from the UNM Data Owner, who will review a specific request, review operational controls, and work with the ISPO to ensure that the appropriate technical controls are defined, in place, and enforced. There is more information at http://data.unm.edu and more information will be forthcoming at that location as it is developed.
IT Agents – I think the intention here was to make sure the local IT support was aware of all of the avenues of communication that we typically use to inform the IT community of changes and support issues. We’ve changed the language to clarify that in the last version.
Support Resources – I see what you mean, but I don’t see an appropriate section in the current document—but it doesn’t mean we shouldn’t create one. This might be another one where it needs to be in alignment with other SLA’s, so I’ll bring it back to the IT Agreements committee.
Calendar – True, but we’re really saying “Do not share your calendar details with everyone unless you really intend to.” We’ve changed the language in the final version to reflect that message.
Attachments – Agreed—I’ve had some issues obtaining data from vendor for the same reason. We can look into that and if we’re successful we could add that as a point in the SLA, but in general I’m not sure we should get into that level of detail regarding how we’re executing a point.
Integration – It doesn’t cover OneDrive/Sharepoint (just FYI) but it’s still a valid question since there are ways of doing Exchange integrations. But again, I’m not sure the SLA is the place for that level of detail, but perhaps the Service Catalog?
Billing – Good point! This is a standard template language. We will share this comment back with the committee.

Thanks Susan.  In cases where a service is elective, charges are only incurred when a decision is made to use the service.  For enterprise services, the working definition is that the service is to be offered exclusively via a central entity, although as of this moment there has not been a directive to exclusively use those services classified by KSA as enterprise.  Funding implications on enterprise services and/or the financial impact of possible exceptions to utilize enterprise services are not defined as of yet. The example of baseline email in particular does not have a charge – it is provided to campus without a pass through of cost based on usage (in our existing model).

Posting for Steve Spence:  This may require further research, but as this service depends upon the underlying NetID service it is also beholden to the same limitations. I will be paraphrasing, but as I recall there was a process of developing a “password standard” some years ago and that group developed the standards documented here: https://unm.custhelp.com/app/answers/detail/a_id/3559. Various parameters in the password were limited to the capabilities of the various systems that would be using the NetId and password for authentication outside of CAS.  

• This reply was modified 8 years, 9 months ago by darruti.