Editor's Pick (1 - 4 of 8)
Microsoft Azure as an 'Infrastructure as a Service'
Digital transformation within Microsoft IT
Uniformity of Data Structures with 365 Apps
Security as a Service from the CIO's Perspective
Roadmap To The Cloud
By Sergio Gallegos, Associate CTO, UCLA Health
For the IT Leadership team at UCLA Health, the decision to make the jump to Office 365 was driven by demand: as an institution, it became necessary to provide what our 30,000 customers had already come to expect–and received–from their personal email and cloud providers: larger mailboxes, cloud storage, instant messaging and other collaboration tools.
Although we provided these services on-premises, they were not meeting our customers’ needs. Before moving to Office 365, we had recently completed a mailbox quota increase from 1Gb to 2Gb standard for all of the enterprise’s users. That increased our on-premise SAN storage allocation for email to 50Tb. However, unfortunately, the service requests and phone calls for larger mailboxes did not stop.
Our users were frustrated, and it affected their work performance. For example, it impacted our researchers’ ability to apply for grants because their applications were exceeding their space quotas. Most were having to spending hours a week combing through emails to find large items to delete so they could clear space to send and receive email with attachments.
Our messaging and customer care teams were also directly impacted as the bulk of their tickets consisted of mail quota increases. They spent most of the day providing temporary increases and dealing with frustrated staff, clinicians, and researchers.
Maintaining an on-premise solution was becoming cost-prohibitive. Even if we were to offer 100 times more storage, we still could not compete with the storage capabilities of Yahoo and Gmail, services our customers were already accustomed to. Providing additional storage was also cost-prohibitive because, as a healthcare provider, our retention policies require that we keep multiple back-up copies of our data. Management of that data and its recovery is extremely labor-intensive.
The decision was clear: we needed to go to the cloud solution if we were to provide cost-effective storage and customer satisfaction. We did consider a few options that would satisfy our security requirements, but ultimately we selected Office 365 for several reasons.
Primarily, it was the compatibility factor; our users were accustomed to the mail platforms we were already using.
With Microsoft's help, building an Azure tenant was easy, but ensuring that it met our security standards and policies required careful review from our security and compliance teams
Financially, the price was right as Microsoft offers Office 365 at no cost for higher education institutions like ours. In addition to much larger mail quotas (50Gb!), the cloud provided Skype for Business, Office WEB Applications, OneDrive for Business, SharePoint Online, and Yammer and several other important programs.
The ascension to the cloud was a challenging one. Office 365 requires identity federation between their identity store and our on-premise Active Directory, so this proved to be where the majority of our efforts were expended. Our messaging team spent weeks cleaning our directory, deleting duplicates and updating records for thousands of users. We also had to establish Active Directory Federation Services (ADFS) and an Azure tenant to host ADFS and our Domain Controllers in the cloud. Both of these services were a first for UCLA. With Microsoft's help, building an Azure tenant was easy, but ensuring that it met our security standards and policies required careful review from our security and compliance teams.
Another challenge on our road to the cloud was our premise environment. We were running Office 2010 on our desktops which was compatible but required some updates for it to work with Office 365. Rather than updating, we decided to invest our efforts in an upgrade to Office 2016 as Office 2016 offered improved compatibility and collaboration features as well as integration with the Office 365 suite. Along with a client update, we also had to update our User Principal Name (UPN) on all of our desktops to accommodate the new federated login.
Once our on-premise environment, which consists of more than 25,000 desktops across the UCLA Health Sciences enterprise was completed, we were ready for migrations.
We outsourced the migrations to Microsoft as part of their rapid deployment program. We provided them with a schedule for the migrations, and then Microsoft performed the migrations. The migration phase of the project was very successful. Only a few mailboxes needed to be manually copied to the cloud by our messaging team.
Another factor in our success was that we contracted with Microsoft to help us with our build. We were assigned dedicated resources and engineers, including weekly on-premises all-day working sessions. This allowed us to expeditiously resolve issues that emerged during the build process.
The area where we initially struggled with was Office 365 license management for new staff. We use Microsoft's Forefront Identity Management (FIM) solution for access and provisioning. Unfortunately, we were not able to complete the FIM programming before our go-live, so our messaging team was manually assigning Office 365 licenses. We recently completed the FIM enhancements, and our Identity and Access Management teams now have the ability to assign Office 365licensing through FIM.
We have now been in production for more than five months with no major issues.
Our messaging team and customer care teams are standing by waiting for the first ticket requesting a mail quota increase. To date, we have not received that call.
UCLA Health System is an academic medical center which comprises a number of hospitals and an extensive primary care network in the Los Angeles region.