updates to hardware (such as firmware and BIOS) plus deploy updates for Microsoft
and non-Microsoft applications.
The same idea applies to all aspects of your datacenter. Try to stay away from point
solutions. System Center Operations Manager (SCOM) can monitor your physical
servers, the virtual servers, the operating system, applications, custom .NET and J2E
applications, networking equipment, and even non-Windows workloads in addition to
monitoring and integrating with Microsoft Azure. This gives you a complete view,
from soup to nuts as they say. The same applies for backup, for service management,
and for orchestration; keep it simple and minimize the number of separate tools.
From a virtual machine management perspective, Windows Azure Pack or Microsoft
Azure Stack can provide a single view of on-premises virtual machines that are
managed by System Center Virtual Machine Manager (SCVMM) or Microsoft Azure
Stack and of virtual machines running in Microsoft Azure and even of virtual
machines running with hosters that leverage Service Provider Foundation (SPF) or
Azure Stack with the right configuration and third-party add-ons. The same can apply
to provisioning with more complex workflows using System Center Service Manager
(SCSM) to provide a service catalog fronting many services, including virtual machine
provisioning and management.
Orchestration is where I would like to finish because it brings together everything
about the datacenter. As organizations use more and more IT, and your organization
will have more and more operating system instances to manage, technologies like
service templates help to bring the focus to the application instead of the operating
system. However, many operating systems will still require management. To truly
scale, you must look at automation capabilities and working with multiple operating
system instances at the same time.
PowerShell is a key part of enabling automation. Especially in Windows Server 2012
and above, basically everything that can be done with the GUI can also be done with
PowerShell. Actions can be scripted, but more important, they can be executed on
many machines concurrently and in an automated fashion. Building on orchestrating
tasks and beyond just PowerShell, takes some time to look at System Center
Orchestrator. Every client I talk to gets very excited about Orchestrator in terms of its
ability to connect to any system that exists through various methods and then to
create runbooks based on PowerShell workflows, which are sets of actions that should
be performed in a sequence and based on results from previous actions across all of
those connected systems. Start with something small, some set of actions that you
perform manually each day, and automate them in Orchestrator. Another good way to
learn is to take a simple PowerShell script that you have and integrate it in
Orchestrator instead. Note that Orchestrator historically was based around graphical
runbooks built from actions defined in integration packs. It has now shifted, however,
to be built on PowerShell workflows, which has the benefit of not requiring separate
packages of actions to be built for a single product and instead can leverage
PowerShell modules that are widely used. Because of this shift, I advise my customers