June 24, 2022
|
4
min read
Roy Martinez
With over 16 years in Microsoft and IT infrastructure, Roy uses his SharePoint, Power Automate, and Microsoft Teams expertise to help organizations develop strategies for adoption, collaboration, automation, and governance.

PowerShell is a scripting language and a shell environment built into a single tool. It is often used for simplifying administrative tasks in Office 365 and can be a significant time-saver. There is a tendency among these practitioners to create and store the tools they create in less-than-optimal ways.

For example, suppose an IT engineer needs to find and update all users in Azure AD that meet a certain criterion, and to then update those users somehow – grant them some specific permission, say. PowerShell is an excellent candidate for this task, and it will probably serve IT engineers quite well.

But what if another engineer needs to execute the same task or even a similar task? The second engineer will need to write the same thing from scratch – thereby duplicating effort and reducing the IT department’s overall efficiency. Moreover, one script will very likely do some things better or more efficiently than the second, and vice versa.

That is unless the first engineer shared the script somehow and the two engineers were able to collaborate. Or better yet, if the first engineer had checked that script into a centralized version control system where other IT staff could find it and potentially make changes that could also be checked into version control. Then any number of versions would be saved for future use, and they would each probably be better, more efficient scripts for their having been thought through by multiple engineers over time, rather than just the one.

This idea of creating code-based resources that are stored in a way that allows changes to be tracked over time is central to the field of DevOps and modern software development. And while IT teams may not think of their custom scripts as such, they really are exactly the same thing as any other piece of software. They are text files that can be saved and shared among staff to eliminate duplicated effort, while also serving as a means for creative collaboration and thus increasing the IT department’s efficiency in executing all sorts of tasks.  

DevOps Practices for Office 365 Admins

DevOps is a relatively new field that aims to smooth the transition between software developers, who write the software, and operations teams, who maintain the software once it’s been deployed. And while there are lots of elements to this, there are two main components that are absolutely essential, and – ironically enough – we’ve already talked about both of them in the context of PowerShell scripts above.

Automation

Automation is the cornerstone of modern DevOps. It allows teams to move quickly with a high degree of confidence that things will be as they are supposed to be, because there is a dramatically reduced risk of user error when a task has been well defined, and that task is then carried out by a computer, rather than a person.

Automation in the O365 admin’s world is equally valuable in terms of its ability to reduce the risk of errors being made when repetitive tasks need to be carried out regularly. Moreover, it also makes for more efficient work and a more enjoyable experience for IT staff when they no longer need to carry out mundane tasks manually time and again. And, of course, there is the added business value of freeing up IT staff to solve new problems, rather than spending their time and energy managing O365 manually.

Version control

Version control software, such as Git, is ubiquitous in the software development landscape. It is so common because it just makes sense. Saving files as they are updated and keeping records of past versions of files in a way that allows colleagues to access and update them as needed, while still maintaining any past versions is the standard approach to developing software, and writing PowerShell scripts, as we’ve already established, is really no different. So, it stands to reason that PowerShell scripts ought to be maintained in a similar way.

CoreView Makes this Simple

Incorporating these central elements of modern DevOps in an IT workflow is simple with CoreView.

Automation

CoreView empowers IT engineers to automate repetitive tasks – regardless of their degree of complexity. In fact, most common practices that an IT department would need to automate in O365 have pre-built actions that an administrator can simply select from an existing menu. And for those cases in which a custom PowerShell script is the preferred solution, CoreView allows administrators to create custom actions based on bespoke scripts that your engineers are already comfortable with.

Version control

In addition to allowing IT teams to create custom automations with their custom scripts, it also serves as a central hub in which these scripts can be stored, shared, and accessed by authorized personnel as needed. This way, when a custom action in a CoreView workflow partially accomplishes the desired task, colleagues of the original engineer who wrote it can access and update it – even if that original engineer is no longer with the organization.

This persistent, centralized approach to storing custom IT-created resources then works as an efficiency-building element in multiple ways. Scripts no longer need to be written and rewritten to accomplish the same task, and scripts can be accessed and updated as needed to accomplish similar tasks – regardless of whether the original engineer is still available to share the script. It will simply become an IT department resource that any authorized engineer can access as needed.

Takeaways

DevOps is a relatively new idea in the realm of software development. And while there are many aspects to DevOps, automating repetitive processes and managing code with version control are two fundamental elements that can easily be adapted to improve the efficiency of IT workflows in O365.

CoreView makes it simple to both automate processes with both pre-built and custom PowerShell scripts in a way that will dramatically reduce the chance of human error, and that will also empower the colleagues of the engineer who originally wrote the custom action to bot reuse it and modify it when the need arises.

Ready to make Microsoft 365 work for you? Let us show you how.

Get a demo