WEBVTT
00:00:00.160 --> 00:00:02.010
Hello, and welcome everyone
to our session today.
00:00:02.010 --> 00:00:07.780
We'll be talking about running and
managing Linux with Windows Server,
00:00:07.780 --> 00:00:10.300
System Center and Azure Pack.
00:00:10.300 --> 00:00:13.210
My name is Kristopher Bash,
and my colleague.
00:00:13.210 --> 00:00:14.660
>> I'm Anurag Gupta.
00:00:14.660 --> 00:00:18.374
>> We're both program managers
in a team at Microsoft called
00:00:18.374 --> 00:00:21.346
the Open Source Technology Center,
or OSTC.
00:00:21.346 --> 00:00:24.057
As actually a product
development team,
00:00:24.057 --> 00:00:28.705
we're part of the Windows server
organization, and we do development
00:00:28.705 --> 00:00:33.042
work supporting quite a breadth of
Linux and Unix capabilities and
00:00:33.042 --> 00:00:37.701
systems center, Windows server and
then some of the Azure IS support.
00:00:40.228 --> 00:00:43.060
Has everyone seen this slide?
00:00:43.060 --> 00:00:44.610
Few times, hopefully.
00:00:44.610 --> 00:00:47.710
So we've actually been
down in the expo hall,
00:00:47.710 --> 00:00:51.400
giving out some buttons and stickers
that have Microsoft loves Linux.
00:00:51.400 --> 00:00:52.540
We love this slide.
00:00:52.540 --> 00:00:58.410
We've actually been doing
Linux management for
00:00:58.410 --> 00:01:01.680
quite some time,
00:01:01.680 --> 00:01:06.340
going back 2009 with ops manager
Unix and Linux monitoring.
00:01:06.340 --> 00:01:10.010
Started work on Hyper V
integrations not long after that.
00:01:10.010 --> 00:01:13.130
Linux was supported
in Azure on day one.
00:01:13.130 --> 00:01:17.560
But still it's hard to imagine this
slide being shown three years ago,
00:01:17.560 --> 00:01:20.410
let alone the CEO of Microsoft
standing in front of
00:01:20.410 --> 00:01:21.248
a slide like this.
00:01:21.248 --> 00:01:26.850
What's changed, but
what we really want to
00:01:26.850 --> 00:01:29.330
convey with the slide today is that
there has been this C change, or
00:01:29.330 --> 00:01:32.440
critical mass in Microsoft.
00:01:32.440 --> 00:01:35.130
We're seeing from top down,
across the organization,
00:01:36.850 --> 00:01:40.950
some real thought about rather than
building a future for Windows first,
00:01:40.950 --> 00:01:42.570
and how to we get
that on Linux later.
00:01:42.570 --> 00:01:46.469
We're actually thinking about
Linux as a platform target from
00:01:46.469 --> 00:01:48.280
day one of engineering.
00:01:48.280 --> 00:01:52.978
You've seen some evidence
of this recently with
00:01:52.978 --> 00:01:58.340
.NET core going open source and
being ported to Linux
00:01:58.340 --> 00:02:00.860
with visual studio code announced
last week for Linux and Mac.
00:02:00.860 --> 00:02:03.450
So you know there's, and then of
course Azure is just this constant
00:02:03.450 --> 00:02:06.690
strain with new features coming
out for both Linux and Windows.
00:02:08.260 --> 00:02:12.900
Definitely a huge change for
Microsoft, and we're loving it.
00:02:12.900 --> 00:02:16.800
This is a great time to be working
on Linux features at Microsoft.
00:02:16.800 --> 00:02:21.850
A lot less lonely than
it was five years ago.
00:02:21.850 --> 00:02:22.390
Okay so, why?
00:02:22.390 --> 00:02:29.090
I like to characterize this change
as the triumph of pragmatism.
00:02:29.090 --> 00:02:31.650
This isn't a philosophical change.
00:02:31.650 --> 00:02:35.460
This is just a recognition of
the reality we've been hearing from
00:02:35.460 --> 00:02:40.330
you folks, from our customers,
for years.
00:02:40.330 --> 00:02:42.880
That your data centers are
heterogeneous, that you're running
00:02:42.880 --> 00:02:47.320
Windows, you're running Linux, many
of you I'm sure are running UNIX.
00:02:47.320 --> 00:02:48.790
At the end of the day,
00:02:48.790 --> 00:02:51.680
you just need it able to run,
you need to be able to manage it.
00:02:51.680 --> 00:02:55.570
You need to be able to, you want
a centralized infrastructure,
00:02:55.570 --> 00:02:57.290
a common set of tools.
00:02:57.290 --> 00:03:01.090
You don't want a management stack
for one operating system versus
00:03:01.090 --> 00:03:04.460
another management stack for
another operating system.
00:03:04.460 --> 00:03:06.020
We've internalized that message.
00:03:06.020 --> 00:03:06.920
We get it.
00:03:06.920 --> 00:03:11.270
That's what's driving this change
is just good business for us.
00:03:11.270 --> 00:03:12.710
And at this point I'll let Anurag.
00:03:14.080 --> 00:03:14.600
>> Thanks, Kris.
00:03:16.350 --> 00:03:19.600
So at Ignite this week, you're
gonna see a lot of sessions about
00:03:19.600 --> 00:03:23.790
the public cloud, some of the great
management we're bringing with OMS,
00:03:23.790 --> 00:03:27.340
but today's session, we're
gonna focus on running Unix and
00:03:27.340 --> 00:03:29.490
Linux in your data center today.
00:03:29.490 --> 00:03:32.060
We're gonna talk about your
traditional environments that might
00:03:32.060 --> 00:03:34.330
have Windows, Linux, or Unix.
00:03:34.330 --> 00:03:35.970
I'm bringing that to
the virtualized environment,
00:03:35.970 --> 00:03:40.640
and then Microsoft's public
cloud with Windows and Linux.
00:03:40.640 --> 00:03:43.720
And so, this is going to
be a 200 level session.
00:03:43.720 --> 00:03:47.198
We're really gonna focus on what you
can do today with System Center and
00:03:47.198 --> 00:03:49.020
Hyper-V 2012 R2.
00:03:49.020 --> 00:03:52.146
So right after this session, you
know, many of you will go out and
00:03:52.146 --> 00:03:56.080
start managing Linux today,
I'll put a bet on it.
00:03:57.230 --> 00:04:01.450
So a brief agenda, so first we're
gonna go to an introduction of what
00:04:01.450 --> 00:04:06.990
products we offer, what it is,
the level of Microsoft and Linux.
00:04:06.990 --> 00:04:09.290
What operating systems
are supported.
00:04:09.290 --> 00:04:12.040
Talk about running and
deploying Linux.
00:04:12.040 --> 00:04:14.120
What Linux integration services are,
00:04:14.120 --> 00:04:17.020
virtual machine manager,
Windows Azure Pack.
00:04:17.020 --> 00:04:21.590
And then step into managing and
monitoring Linux, with System Center
00:04:21.590 --> 00:04:25.430
configuration manager, System Center
operations manager, and
00:04:25.430 --> 00:04:29.160
lastly, automation with desired
state configuration, or DSC.
00:04:30.930 --> 00:04:33.670
So, supported operating systems,
if you came by our booth,
00:04:33.670 --> 00:04:35.920
you might have seen this slide up.
00:04:35.920 --> 00:04:41.160
Great slide showing we're not just
going one in Linux version and
00:04:41.160 --> 00:04:44.180
saying, yeah, Microsoft
supports Linux running there.
00:04:44.180 --> 00:04:47.030
No, we've actually gone after
most of the Enterprise Linuxes.
00:04:47.030 --> 00:04:53.770
So you've got Red Hat, SUSE, CentOS,
Ubuntu, Debian and Oracle Linux.
00:04:53.770 --> 00:04:56.260
And we've also done the work for
managing and
00:04:56.260 --> 00:04:58.400
monitoring the proprietary UNIXs.
00:04:58.400 --> 00:05:03.470
So, IDM AIX, HP HP-UX,
and Oracle Solaris.
00:05:03.470 --> 00:05:08.130
And Kris had mentioned 2009
operations manager support started.
00:05:08.130 --> 00:05:09.540
We've been doing this for a while.
00:05:09.540 --> 00:05:11.336
A 2010 Hyper-V came out.
00:05:11.336 --> 00:05:15.220
In 2013 day one, IEZ Linux VMs.
00:05:15.220 --> 00:05:19.210
And we're not really going after
the hobbyist VMs so your Fedora,
00:05:19.210 --> 00:05:21.880
Mint, even Hannah Montana Linux.
00:05:21.880 --> 00:05:25.870
That's not gonna be anytime
represented this matrix soon.
00:05:27.090 --> 00:05:30.290
And we understand there's
some more boxes to fill here.
00:05:31.630 --> 00:05:32.130
Stay tuned.
00:05:33.740 --> 00:05:35.850
So running and deploying Linux.
00:05:35.850 --> 00:05:37.850
This is gonna start
off with Hyper-V.
00:05:37.850 --> 00:05:41.450
And Integration Services,
what are they?
00:05:41.450 --> 00:05:46.560
So Hyper-V is going to present
synthetic devices to the guest OS,
00:05:46.560 --> 00:05:48.310
its disc drive or network adapter.
00:05:48.310 --> 00:05:51.950
And then your Guest OS is going to
say, hey, I need some drivers for
00:05:51.950 --> 00:05:53.180
these devices.
00:05:53.180 --> 00:05:56.990
And that's where integration
services are going to come in.
00:05:56.990 --> 00:06:00.845
These are going to be the guest
OS drivers for Hyper-V.
00:06:00.845 --> 00:06:04.577
These are drivers written for
that specific Guest OS, so
00:06:04.577 --> 00:06:09.489
Red Hat or SUES might need something
different for that synthetic device.
00:06:10.970 --> 00:06:14.540
We're making sure that we're
riding for that platform.
00:06:14.540 --> 00:06:17.510
So your Windows integration services
are different than your Linux
00:06:17.510 --> 00:06:18.850
integration services,
00:06:18.850 --> 00:06:22.410
which are different from your
FreeBSD integration services.
00:06:22.410 --> 00:06:25.930
And then we've also done the work
to make sure there's specific
00:06:25.930 --> 00:06:27.200
drives for
00:06:27.200 --> 00:06:30.550
user space daemons that are gonna
be interacting with these drivers.
00:06:32.470 --> 00:06:35.450
And then secondly with
Linux Integration Services,
00:06:35.450 --> 00:06:36.830
what are the versions supported?
00:06:36.830 --> 00:06:39.400
How am I gonna go get it?
00:06:39.400 --> 00:06:42.270
So in the matrix you saw we're
going after all the enterprise
00:06:42.270 --> 00:06:43.510
Linux's there.
00:06:43.510 --> 00:06:46.880
There's a breakdown of
the versions and LIS availability.
00:06:48.530 --> 00:06:50.960
So the first way you're going
to go get these packages,
00:06:50.960 --> 00:06:52.550
you're going to go online and
download it.
00:06:52.550 --> 00:06:55.520
And the second is
you already have it.
00:06:55.520 --> 00:06:58.310
We've done the work to
commit to the Linux kernal.
00:06:58.310 --> 00:07:00.410
Those changes have been
picked up upstream.
00:07:00.410 --> 00:07:03.410
And we've worked with distribution
vendors to get those drivers
00:07:03.410 --> 00:07:06.390
integrated with your
favorite enterprise Linux.
00:07:07.440 --> 00:07:10.420
And then, of course,
your support strategy.
00:07:10.420 --> 00:07:13.270
How do I get support for
my Linux running on Hyper-V?
00:07:13.270 --> 00:07:16.730
We've worked with the vendors to
make sure that you can contact them
00:07:16.730 --> 00:07:17.900
directly, and
00:07:17.900 --> 00:07:21.870
if you have Hyper-V issues you can
contact the Linux vendor or us.
00:07:21.870 --> 00:07:24.300
And lastly,
if you guys are not aware,
00:07:24.300 --> 00:07:27.450
LIS 4.0 came out earlier this week.
00:07:27.450 --> 00:07:28.480
Publicly announced.
00:07:28.480 --> 00:07:32.000
And that's going to be a bunch
of performance upgrades and
00:07:32.000 --> 00:07:33.350
XIO improvements, so
00:07:33.350 --> 00:07:36.020
I highly recommend you guys go
out and download that as well.
00:07:38.430 --> 00:07:38.940
And with that,
00:07:38.940 --> 00:07:42.641
I will hand it off to Kris,
who will talk about deploying Linux.
00:07:42.641 --> 00:07:44.950
>> Thanks, Anurag.
00:07:44.950 --> 00:07:48.470
So when we talk about
the Microsoft private story,
00:07:48.470 --> 00:07:52.260
we're really starting with System
Center Virtual Machine Manager.
00:07:54.240 --> 00:07:57.510
VMM has kinda two key roles
in the private cloud.
00:07:57.510 --> 00:07:59.390
First it's your fabric manager.
00:07:59.390 --> 00:08:04.030
Define your networking, your
storage, you can manage your host,
00:08:04.030 --> 00:08:04.989
your hypervisors.
00:08:06.220 --> 00:08:10.300
Just recently VMM
added the ability to
00:08:10.300 --> 00:08:13.130
do some management of your
AWS in Azure VM assets.
00:08:13.130 --> 00:08:16.930
So that's a cool new feature.
00:08:16.930 --> 00:08:19.640
VMM also allows you to build
out some templates, so
00:08:19.640 --> 00:08:21.790
VM templates, service templates,
00:08:21.790 --> 00:08:25.930
which are multi-tiered VM
template implementations.
00:08:25.930 --> 00:08:28.520
And then deploy those,
manage those VMs.
00:08:30.050 --> 00:08:32.400
Start, stop, snapshot,
that kind of thing.
00:08:33.550 --> 00:08:36.740
Azure Pack is a, and
again as a reminder,
00:08:36.740 --> 00:08:41.450
we're focused on technologies that
are generally available today.
00:08:41.450 --> 00:08:45.580
So when we talk about Azure Pack,
we're talking about Azure Pack 2,
00:08:45.580 --> 00:08:48.840
which is available now,
not the new Azure Stack,
00:08:48.840 --> 00:08:50.320
which was announced
earlier this Week.
00:08:52.310 --> 00:08:55.995
Azure Pack is a really
around bringing that kind of
00:08:55.995 --> 00:09:00.160
multi-tenant Azure portal
experience into your data center.
00:09:01.320 --> 00:09:06.060
Primarily looking at using VMM as
the underlying fabric for that,
00:09:06.060 --> 00:09:10.860
that's actually integrated
through a component called SPF,
00:09:10.860 --> 00:09:14.200
which does that
fabric-to-tenant integration.
00:09:14.200 --> 00:09:19.230
And it really lets you have a nice
self-service portal that's very
00:09:19.230 --> 00:09:23.520
familiar, because it shares
some UI with the Azure portal.
00:09:27.530 --> 00:09:31.260
So VMM we added Linux
specialization support,
00:09:31.260 --> 00:09:35.170
VM templates for
Linux back in the 2012 SP1 release.
00:09:37.150 --> 00:09:41.060
So for Linux VM template really
consists of three parts.
00:09:41.060 --> 00:09:47.320
First we have a VHD or VHDX image
with the Linux operating system.
00:09:47.320 --> 00:09:49.970
So we would start with
building out our image
00:09:49.970 --> 00:09:51.470
probably by mounting a DVD.
00:09:51.470 --> 00:09:55.863
An ISO DVD of the Linux OS,
build out the Linux OS,
00:09:55.863 --> 00:10:01.310
get it configured generally how
we want our template to look.
00:10:01.310 --> 00:10:04.470
Make sure that the LISD
integration services are there.
00:10:04.470 --> 00:10:08.640
For most modern Linux versions,
that's going to be built in.
00:10:08.640 --> 00:10:10.760
And then we would
install the VMM agent.
00:10:10.760 --> 00:10:15.900
The VMM agent is a very trivial and
ephemeral agent that
00:10:17.490 --> 00:10:23.240
implements kind of analogous
behavior to Sysprep on Windows.
00:10:23.240 --> 00:10:25.838
It's gonna do some
depersonalization,
00:10:25.838 --> 00:10:29.847
like flushing out your batch history
so when you deploy a new VM,
00:10:29.847 --> 00:10:34.280
you can't see what commands were
run before that from that template.
00:10:34.280 --> 00:10:35.870
[LAUGH] And
00:10:35.870 --> 00:10:40.800
then in the VMM agent, it is also
going to do the personalization.
00:10:40.800 --> 00:10:44.970
It's going to set the networking and
the host name and things like that.
00:10:44.970 --> 00:10:48.650
We take that VHD and then we combine
it with a hardware profile, which
00:10:48.650 --> 00:10:54.310
just defines the virtual hardware
of memory, CPU, things like that.
00:10:54.310 --> 00:10:58.870
Just as Linux and Windows can run
on the same physical hardware,
00:10:58.870 --> 00:11:02.890
Linux and Windows use the same
hardware profile VMM in fact there's
00:11:02.890 --> 00:11:05.610
actually no code difference
there in the hardware profile.
00:11:07.090 --> 00:11:10.350
And then the last part of our
VM template is the OS profile,
00:11:10.350 --> 00:11:12.240
which is Linux specific.
00:11:12.240 --> 00:11:15.440
We certainly didn't want to shoe
horn Window's operating system
00:11:15.440 --> 00:11:19.290
settings onto Linux and do some
kind of weird abstraction there.
00:11:19.290 --> 00:11:22.240
So that's all specific
code at that point.
00:11:22.240 --> 00:11:24.730
VMN knows you're working with Linux.
00:11:24.730 --> 00:11:28.314
You're presented options for
your DNS domain name,
00:11:28.314 --> 00:11:30.702
your root password and ssh key, and
00:11:30.702 --> 00:11:35.094
we'll definitely look at these
Run Once command lines in a demo.
00:11:35.094 --> 00:11:39.692
Those are your primary extensibility
options with VMM for Linux.
00:11:39.692 --> 00:11:43.513
It's a set of arbitrary commands and
you can order them,
00:11:43.513 --> 00:11:46.935
you can actually set
individual time outs on them,
00:11:46.935 --> 00:11:50.210
that are run after the VMM
has been specialized.
00:11:50.210 --> 00:11:54.729
So at that point, your host name
is set, your network is up, and
00:11:54.729 --> 00:11:58.331
you can use those to install
additional software,
00:11:58.331 --> 00:12:01.011
to bootstrap
a configuration agent or
00:12:01.011 --> 00:12:05.896
to do additional customization that
wasn't part of the OS profile.
00:12:09.146 --> 00:12:12.268
Walking through how
this actually works,
00:12:12.268 --> 00:12:17.134
it's very similar to the way a
Windows VM is specialized with VMM.
00:12:17.134 --> 00:12:21.521
We start with a VMM server
as a library with our VHDs,
00:12:21.521 --> 00:12:25.330
has our database for
our templates defined.
00:12:25.330 --> 00:12:29.997
When you go to deploy the VM, VMM
will generate a specialization dock.
00:12:29.997 --> 00:12:32.772
This is if you're
familiar with Windows,
00:12:32.772 --> 00:12:37.012
you can think of this as your
unattend.XML, it's actually much
00:12:37.012 --> 00:12:41.960
less complex than unattend.XML so
it's pretty straightforward.
00:12:41.960 --> 00:12:46.840
That specialization doc and the
latest version of the VMM agent for
00:12:46.840 --> 00:12:50.670
Linux known to the server,
are put on an ISO.
00:12:50.670 --> 00:12:53.733
That's all shipped out
to the hypervisor host.
00:12:53.733 --> 00:12:57.989
The host agent creates the VM
from the specification,
00:12:57.989 --> 00:13:02.626
mounts the ISO in the virtual
DVD drive, and boots that VM.
00:13:02.626 --> 00:13:06.340
When you installed the VMM agent,
when you were preparing that VHD,
00:13:06.340 --> 00:13:09.240
it actually registered
itself as a Daemon.
00:13:09.240 --> 00:13:14.020
So when that VM boots up,
the VMM agent is going to fire up.
00:13:14.020 --> 00:13:19.830
It'll check the DVD drive, try to
find the specialization document.
00:13:19.830 --> 00:13:23.840
If it finds that, it then compares
the agent version on the ISO to
00:13:23.840 --> 00:13:25.610
the agent version it has installed.
00:13:26.710 --> 00:13:31.257
And if the agent version on the ISO
is newer, it will upgrade itself.
00:13:31.257 --> 00:13:35.252
That's actually so
we can do bug fixes, add features,
00:13:35.252 --> 00:13:39.332
without you having to go and
crack open all your VHD's and
00:13:39.332 --> 00:13:44.097
upgrade the agent every time we
issue an updated roll-up for VMM.
00:13:44.097 --> 00:13:46.030
At that point,
it does this specialization.
00:13:46.030 --> 00:13:49.350
It sets the host name,
it sets the network configuration,
00:13:49.350 --> 00:13:54.630
it runs a run once command,
sets your credentials.
00:13:54.630 --> 00:13:55.830
And then it shuts down to
00:13:57.080 --> 00:14:00.820
indicate to the VMM server
that it's successful.
00:14:00.820 --> 00:14:08.490
So pretty straightforward,
but it's hugely useful.
00:14:08.490 --> 00:14:10.380
Azure Pack we'll look at in a demo.
00:14:12.950 --> 00:14:15.900
For the most part Azure
pack just works for Linux.
00:14:15.900 --> 00:14:20.100
There's really not a lot that
has to have to be done there
00:14:20.100 --> 00:14:21.980
to make Azure pack work with Linux.
00:14:21.980 --> 00:14:23.660
It has from it's first offering.
00:14:26.080 --> 00:14:29.960
With Azure pack you can, of course,
expose your Linux VM templates
00:14:29.960 --> 00:14:34.100
from VMM into Azure pack show
those out to subscriptions.
00:14:34.100 --> 00:14:37.250
And just use those as
stand alone VM Templates.
00:14:37.250 --> 00:14:39.790
You can also author VM Roles.
00:14:39.790 --> 00:14:44.687
VM Roles give you a little bit
more ability to parametrize your
00:14:44.687 --> 00:14:49.676
configuration, and then,
again with the VM Role, you can use
00:14:49.676 --> 00:14:54.874
the run once command as a means
of doing extended configuration.
00:14:54.874 --> 00:15:00.842
Let's have a look at how
this actually plays out.
00:15:00.842 --> 00:15:03.000
So we're looking at
a VMM server here.
00:15:04.020 --> 00:15:07.500
I have a couple of VM templates,
one for CentOS and one for Ubuntu.
00:15:10.260 --> 00:15:13.660
And of course, the hardware here,
I've defined my processors,
00:15:13.660 --> 00:15:17.820
the memory and the disk
drive where it's referencing
00:15:17.820 --> 00:15:21.800
the VHD I created that
had LIS built in and
00:15:21.800 --> 00:15:26.950
the VMM agent installed course
I can set the networking.
00:15:26.950 --> 00:15:31.930
Then for the OS configuration,
all the name pattern, behavior, VMM,
00:15:31.930 --> 00:15:38.760
around incrementing numbers and
the names and
00:15:38.760 --> 00:15:42.750
using star for randomly generating
name that's all works through Linux.
00:15:43.790 --> 00:15:46.695
And set our root credentials and
time zone and
00:15:46.695 --> 00:15:49.230
set public SSH keys for
the route user.
00:15:50.280 --> 00:15:52.570
And then these run once commands
that I talked about earlier,
00:15:52.570 --> 00:15:57.050
we're actually bootstrapping
the DSE for Linux Agent,
00:15:57.050 --> 00:15:59.950
which we'll demo later
in this session.
00:15:59.950 --> 00:16:01.674
If you're using Chef for Puppet,
00:16:01.674 --> 00:16:03.524
this is a great place
to inject that.
00:16:03.524 --> 00:16:06.956
And the way I'm injecting that is
actually by just doing a W and
00:16:06.956 --> 00:16:09.530
pulling it down from
an internal web server and
00:16:09.530 --> 00:16:11.186
then doing an installation.
00:16:11.186 --> 00:16:14.752
So that's a great way to kind
of bootstrap your next order
00:16:14.752 --> 00:16:16.620
of configuration for the VM.
00:16:22.610 --> 00:16:25.814
Now tab over to Azure pack here.
00:16:25.814 --> 00:16:31.101
So those two VM templates simply
show up as my, because I've shared
00:16:31.101 --> 00:16:35.850
those out subscription,
as my gallery for a stand alone VM.
00:16:37.160 --> 00:16:44.030
So I could go through and deploy my
CentOS VM, provided a name, a ROOT
00:16:44.030 --> 00:16:48.730
password and paste in my SSH key for
my ROOT user, you kick that out.
00:16:50.340 --> 00:16:53.825
I've also gone ahead and
created some VM rolls,
00:16:53.825 --> 00:16:56.885
largely abstracting
that same template.
00:16:59.021 --> 00:17:01.064
But it gives me a little
more flexibility.
00:17:05.894 --> 00:17:08.939
So I'll deploy a VM role here,
and pick the size, and
00:17:08.939 --> 00:17:12.880
this would control the hardware
that's allocated to it.
00:17:12.880 --> 00:17:14.910
I'll just call it ignite VM.
00:17:17.340 --> 00:17:20.020
And in this case I'm actually
because I want to, instead of
00:17:20.020 --> 00:17:25.600
using root, I want to lower user,
a non-privleged user with sudo.
00:17:25.600 --> 00:17:29.110
I've set that up in the UI
in the VM Role template and
00:17:29.110 --> 00:17:31.390
I have some run once commands
that make that happen.
00:17:33.340 --> 00:17:34.270
And I can kick that out.
00:17:35.610 --> 00:17:38.724
Of course on the VM roles,
we can go in and
00:17:38.724 --> 00:17:43.594
look at a previously deployed one,
drill into our instances.
00:17:43.594 --> 00:17:45.940
We could scale that out.
00:17:45.940 --> 00:17:51.140
Of course, this is all accessible
through programmatic APIs as well.
00:17:51.140 --> 00:17:53.050
So if I wanted to scale
out of the VM role,
00:17:53.050 --> 00:17:55.180
I could save that configuration.
00:17:56.780 --> 00:17:59.170
So, pretty cool private cloud stuff.
00:17:59.170 --> 00:18:01.900
Totally viable for
Linux, available now.
00:18:04.770 --> 00:18:11.270
And we'll switch back to here
with moving into Management.
00:18:11.270 --> 00:18:12.230
>> Thanks.
And so
00:18:12.230 --> 00:18:13.580
just a quick poll of the room.
00:18:13.580 --> 00:18:17.490
How many of you guys are Windows
Admins that have now been tasked
00:18:17.490 --> 00:18:18.330
with managing Linux?
00:18:19.750 --> 00:18:21.860
Cool, okay, okay, a lot of the room.
00:18:21.860 --> 00:18:23.061
All right, good to see, good to see.
00:18:23.061 --> 00:18:24.106
Glad you're here.
00:18:24.106 --> 00:18:27.690
We're gonna talk about
the solutions we have.
00:18:27.690 --> 00:18:30.000
So first up,
we have system center components.
00:18:30.000 --> 00:18:34.110
We have Configuration Manager and
systems center Operations Manager.
00:18:34.110 --> 00:18:38.270
With Configuration Manager,
you're gonna have three scenarios.
00:18:38.270 --> 00:18:40.660
You're gonna first have
hardware inventory.
00:18:40.660 --> 00:18:43.380
That's gonna give you a component
layout of what your Linux servers
00:18:43.380 --> 00:18:47.630
have, what installed applications
you have, and you can ahead and
00:18:47.630 --> 00:18:50.340
create collections based off that.
00:18:50.340 --> 00:18:52.040
Secondly, you have
software distribution.
00:18:52.040 --> 00:18:55.940
So, you can deploy packages
to your Linux servers.
00:18:55.940 --> 00:18:59.550
You can deploy packages to your
UNIX servers, arbitrary maintenance
00:18:59.550 --> 00:19:02.590
scripts, maybe you have a Python
script that needs to go run.
00:19:02.590 --> 00:19:03.840
And, lastly, reporting.
00:19:03.840 --> 00:19:06.850
So you can report on
that hardware inventory.
00:19:06.850 --> 00:19:10.690
You can report on the success
of a software distribution, and
00:19:10.690 --> 00:19:14.860
that will extend across your
Windows and Linux servers.
00:19:14.860 --> 00:19:16.880
And, finally,
you have endpoint protection.
00:19:16.880 --> 00:19:18.740
That's available as well.
00:19:18.740 --> 00:19:22.390
And then Operations Manager, that's
gonna be your day to day monitoring.
00:19:22.390 --> 00:19:26.010
We have a Linux agent that goes
out onto your Linux server or
00:19:26.010 --> 00:19:29.240
UNIX server and
will get OS health and performance.
00:19:29.240 --> 00:19:30.940
And that's gonna be
specific to Linux.
00:19:30.940 --> 00:19:34.970
So I-Nodes and Swap Space,
give you alerting on that.
00:19:34.970 --> 00:19:38.020
And then on the next level of what's
running on your Linux machines, we
00:19:38.020 --> 00:19:43.470
can monitor the log files that are
in there, specific shell commands.
00:19:43.470 --> 00:19:48.465
And also Java application servers,
as well as line of business apps and
00:19:48.465 --> 00:19:50.305
database and web servers.
00:19:50.305 --> 00:19:52.645
And also at the end you
have audit security events.
00:19:52.645 --> 00:19:57.526
So say Chris over here is soothing
his root, a lot of times more than
00:19:57.526 --> 00:20:01.895
he should, I can go ahead and
discipline him as necessary.
00:20:01.895 --> 00:20:06.110
So stepping into Configuration
Manager, an Architecture Overview.
00:20:06.110 --> 00:20:11.740
So in the green we have our
existing ConfigMgr 2012 R2 setup.
00:20:11.740 --> 00:20:14.700
This is whatever you have today,
what took
00:20:14.700 --> 00:20:17.960
you a couple of months to set up on
Windows, it's gonna be the same.
00:20:17.960 --> 00:20:20.040
You're not gonna be adding
new management points,
00:20:20.040 --> 00:20:21.660
new distribution points.
00:20:21.660 --> 00:20:24.920
It's what's there works.
00:20:24.920 --> 00:20:28.160
And in the blue you had the Linux,
or UNIX server, and
00:20:28.160 --> 00:20:30.550
the first thing we
have is the client, and
00:20:30.550 --> 00:20:33.370
it's the equivalent of
ccmexec.exe on Windows.
00:20:33.370 --> 00:20:36.701
So we've actually named it
ccmexec.bin on the Linux side,
00:20:36.701 --> 00:20:40.882
and that's what's gonna be doing the
communication with your measurement
00:20:40.882 --> 00:20:42.790
points and distribution points.
00:20:44.100 --> 00:20:46.670
And then secondly you
have the OMI server.
00:20:46.670 --> 00:20:50.590
That's a CIM server, stands for
open management infrastructure.
00:20:50.590 --> 00:20:54.850
And this was jointly developed by
Microsoft and the Open Group, and so
00:20:54.850 --> 00:20:55.730
you can go out and
00:20:55.730 --> 00:20:58.330
look at the source code
from the Open Group today.
00:20:58.330 --> 00:21:02.220
They just updated to 1.08,
so great stuff there.
00:21:02.220 --> 00:21:05.280
It's the equivalent of
WMI service in Windows.
00:21:05.280 --> 00:21:07.740
So you have a provider-based model.
00:21:07.740 --> 00:21:09.910
It's your WMI providers on Windows,
00:21:09.910 --> 00:21:12.080
you have OMI providers on Linux and
Unix.
00:21:12.080 --> 00:21:16.940
And if you have custom requirements
that you need to grab specific OS
00:21:16.940 --> 00:21:20.490
resources, you can write custom OMI
providers and plug that right in.
00:21:22.120 --> 00:21:23.490
Oh, sorry.
I see you taking a picture,
00:21:23.490 --> 00:21:25.690
do you wanna [LAUGH]?
00:21:25.690 --> 00:21:26.720
So Hardware Inventory.
00:21:28.930 --> 00:21:32.650
Hardware inventory,
you can look at a single computer,
00:21:32.650 --> 00:21:35.800
Resource Explorer,
look at what's installed,
00:21:35.800 --> 00:21:39.910
what components are there, what
the installed applications are like.
00:21:39.910 --> 00:21:43.110
So on the Windows side,
we're looking at the MSI database,
00:21:43.110 --> 00:21:45.565
on the Linux side we're
gonna look at your RPM and
00:21:45.565 --> 00:21:50.140
de-package databases full of
OLAs and solid applications and
00:21:50.140 --> 00:21:52.250
the proprietary UNIX side as well.
00:21:53.490 --> 00:21:56.460
Then you can create collections
based off this hardware inventory.
00:21:56.460 --> 00:22:00.860
So say you have OpenSSL with Heart
Bleed, you can create a collection
00:22:00.860 --> 00:22:04.610
of all the computers that have
that specific package, or
00:22:04.610 --> 00:22:07.046
hardware inventory of all
your red hat machines, or
00:22:07.046 --> 00:22:10.430
a collection of all your red hat
machines, or CentoOS machines.
00:22:10.430 --> 00:22:13.060
And then finally,
you can run reports that are gonna
00:22:13.060 --> 00:22:15.910
aggregate a cross Windows Linux and
UNIX.
00:22:15.910 --> 00:22:19.348
So if you're interested in
what your site looks like,
00:22:19.348 --> 00:22:23.309
you can have a report that looks
at all the operating systems and
00:22:23.309 --> 00:22:26.842
all the versions that
are contained for that one point.
00:22:26.842 --> 00:22:30.748
And then Software Deployment, this
is gonna let you deploy packages,
00:22:30.748 --> 00:22:34.721
whether those packages are gonna be
updates to install the applications
00:22:34.721 --> 00:22:36.050
or OS updates.
00:22:36.050 --> 00:22:37.053
You can go ahead and
00:22:37.053 --> 00:22:40.020
distribute those to whatever
collection is required.
00:22:40.020 --> 00:22:42.660
So say I had that open
SSL Heart Bleed bug,
00:22:42.660 --> 00:22:46.240
I could deploy a package for
an update to Open SSL.
00:22:46.240 --> 00:22:50.150
And then finally where it lets you
run arbitrary maintenance scripts.
00:22:50.150 --> 00:22:53.170
So say you have a specific shell
command that you've been running for
00:22:53.170 --> 00:22:56.180
the past five years,
we're not saying to throw that away.
00:22:56.180 --> 00:23:00.390
Once you bring in a configuration
manager, you use our RIX scheduling,
00:23:00.390 --> 00:23:04.290
you use our maintenance mode
windows, have that run and
00:23:04.290 --> 00:23:05.510
get reporting back on it.
00:23:05.510 --> 00:23:09.160
That's one of the things
our customers love is
00:23:09.160 --> 00:23:11.935
running these arbitrary maintenance
scripts and then using that RIX,
00:23:11.935 --> 00:23:14.250
recording that configuration
manager it already has.
00:23:16.140 --> 00:23:20.060
And so, going through a quick
implementation with Windows,
00:23:20.060 --> 00:23:25.960
we're going to specify a package, an
MSI, something else, plus a program.
00:23:27.066 --> 00:23:29.670
Or we'll send an advertisement
to the management point,
00:23:29.670 --> 00:23:32.770
and the Windows Client will say hey,
I've got a policy.
00:23:32.770 --> 00:23:34.520
Let me go ahead and
download that package.
00:23:34.520 --> 00:23:36.545
That'll be through SMB or HTP.
00:23:38.130 --> 00:23:40.170
And then we have that
maintenance window, so
00:23:40.170 --> 00:23:41.300
we'll install during that.
00:23:41.300 --> 00:23:45.450
And then we'll send a status message
back to the management point.
00:23:45.450 --> 00:23:48.670
And so, let me introduce Linux and
Unix here.
00:23:48.670 --> 00:23:51.640
So, same thing, specify a package.
00:23:51.640 --> 00:23:55.740
But this time, it'll be a RPM or
a PKG for Solaris.
00:23:55.740 --> 00:23:57.010
And then a program command line.
00:23:57.010 --> 00:24:01.090
So, your shell command, your BASH
script that's gonna install this.
00:24:01.090 --> 00:24:04.390
You'll send out a Linux and UNIX
advertisement to the same management
00:24:04.390 --> 00:24:07.370
point, and this time your Linux and
UNIX server is gonna go ahead and
00:24:07.370 --> 00:24:09.480
say, hey I need that policy.
00:24:09.480 --> 00:24:12.400
And I'm gonna download that package
from that same distribution point,
00:24:12.400 --> 00:24:13.950
no need to make another one.
00:24:13.950 --> 00:24:17.330
And I'm going to install during a
maintenance window that you set, and
00:24:17.330 --> 00:24:20.899
I'll send the status message back up
to the management point, excuse me.
00:24:20.899 --> 00:24:21.981
And so the Linux and
00:24:21.981 --> 00:24:25.570
UNIX editions are gonna dovetail
with existing console in UI.
00:24:25.570 --> 00:24:28.620
You don't have a different window,
you don't have a different
00:24:28.620 --> 00:24:30.830
management point,
distribution point,
00:24:30.830 --> 00:24:33.950
the same hardware infrastructure and
same paradigm.
00:24:33.950 --> 00:24:36.911
So if you're used to
using SSEM today,
00:24:36.911 --> 00:24:41.321
It's very easy to plug in Linux and
UNIX into that system.
00:24:47.032 --> 00:24:50.028
So I'm gonna go through
a quick demo here.
00:24:50.028 --> 00:24:55.872
So let's go through that scenario
of OpenSSL as I've come down upon
00:24:55.872 --> 00:25:01.730
my data center, and I have to go
ahead and patch it as the IT Admin.
00:25:01.730 --> 00:25:06.640
So here we have all
of the devices or
00:25:06.640 --> 00:25:09.340
servers that are part
of my system and
00:25:09.340 --> 00:25:12.400
you can see my Linux ones are just
gonna plug right into Windows.
00:25:15.800 --> 00:25:16.780
And you can even see that,
00:25:16.780 --> 00:25:19.770
hey Chris deployed his service,
and that showed up here.
00:25:19.770 --> 00:25:22.890
I can go ahead and approve it or
00:25:22.890 --> 00:25:24.670
deny it depending
on what I wanna do.
00:25:24.670 --> 00:25:30.610
And let's go ahead and take look
at some of the hardware resources.
00:25:30.610 --> 00:25:33.930
So I can go ahead and
go to Resource Explorer.
00:25:33.930 --> 00:25:35.100
Look at some hardware.
00:25:37.710 --> 00:25:40.236
So we got a computer system.
00:25:40.236 --> 00:25:41.740
You're gonna look at
what that looks like.
00:25:41.740 --> 00:25:47.130
You have network adapter,
disk drives.
00:25:47.130 --> 00:25:49.910
So what you're used to on Windows
we're using the same system
00:25:49.910 --> 00:25:52.990
tables as we did for Linux and Unix.
00:25:52.990 --> 00:25:56.250
And then I could even start
drilling into some of the installed
00:25:56.250 --> 00:25:57.050
applications.
00:25:57.050 --> 00:26:07.391
So I've gotta nice list here,
so let me filter with OpenSSL. Cool.
00:26:07.391 --> 00:26:07.889
So I can
00:26:07.889 --> 00:26:12.902
drill down into what's exactly
installed on that one system.
00:26:12.902 --> 00:26:15.690
And then I can go ahead and
make collections based off that.
00:26:15.690 --> 00:26:22.511
So here I have CentOS servers,
and CentOS 7 with OpenSSL 1.
00:26:22.511 --> 00:26:27.029
And so I can look at which
computers are part of that,
00:26:27.029 --> 00:26:31.765
deploy updates to that,
deploy updates to CentOS 7.
00:26:35.944 --> 00:26:38.419
And then let me go over here and
00:26:38.419 --> 00:26:42.480
look at a deployment
that I've run previously.
00:26:44.820 --> 00:26:48.570
So there's reporting,
I can look at deployments.
00:26:51.410 --> 00:26:53.514
So this deployment was
running a Yum update.
00:26:53.514 --> 00:26:57.972
So we support those RM maintenance
scripts, so using the native
00:26:57.972 --> 00:27:02.523
package manager like Yum,
AVget and Zipper, all is supported.
00:27:02.523 --> 00:27:07.107
And we can see here that hey, my Yum
update for open SSL was successful
00:27:07.107 --> 00:27:11.691
in both those computers in that
collection, and so let me say, hey,
00:27:11.691 --> 00:27:15.350
now I need to go run a report so
I can feed it up the chain.
00:27:16.430 --> 00:27:19.669
So head up to reports.
00:27:26.333 --> 00:27:29.900
So I can say,
hey what versions are installed?
00:27:29.900 --> 00:27:31.218
We can run that report.
00:27:36.395 --> 00:27:37.603
And loading, loading.
00:27:41.945 --> 00:27:42.790
There we go.
00:27:42.790 --> 00:27:46.540
And I can say okay, print it out,
hand it to my boss, tell him hey,
00:27:46.540 --> 00:27:49.450
we're good to go,
OpenSSL Heartbleed, no problem,
00:27:49.450 --> 00:27:51.756
this data center cuz
we got config manager.
00:27:51.756 --> 00:27:58.450
Okay, switch back to this.
00:27:58.450 --> 00:28:00.540
And so I will pass it off to Chris,
00:28:00.540 --> 00:28:04.020
who will talk about
Operations Management.
00:28:04.020 --> 00:28:06.680
>> Who today is using ops
manager for UNIX and Linux?
00:28:08.940 --> 00:28:12.208
And who is interested but
not currently?
00:28:16.387 --> 00:28:20.163
For those of you who are new to
OpsMgr or are new to using UNIX and
00:28:20.163 --> 00:28:23.429
Linux OpsMgr, I like to get
this out of the way first,
00:28:23.429 --> 00:28:27.570
because there are some differences
in the actual implementation,
00:28:27.570 --> 00:28:29.550
the architecture underneath.
00:28:32.270 --> 00:28:35.480
Once you get above that
architecture into the console,
00:28:35.480 --> 00:28:38.290
into the management packs, a lot
of those difference disappear and
00:28:38.290 --> 00:28:40.850
you have a much more
consistent experience.
00:28:40.850 --> 00:28:45.499
But in the actual agent level,
there are some differences.
00:28:45.499 --> 00:28:48.340
So on this chart on the left side,
00:28:48.340 --> 00:28:51.020
we have a representation
of the management server.
00:28:51.020 --> 00:28:52.600
Our management servers, and
00:28:52.600 --> 00:28:56.910
you have the SDK service, the config
service, the health service.
00:28:56.910 --> 00:29:01.340
And then on the right side you have
your Windows computer with a manage
00:29:01.340 --> 00:29:04.580
Windows computer,
with its own health service.
00:29:04.580 --> 00:29:07.940
When that agent fires up, and it's
all improved in the environment,
00:29:07.940 --> 00:29:10.950
it will pull down configuration
in the form of management packs.
00:29:12.170 --> 00:29:16.440
I will load those work flows
locally, those rules and
00:29:16.440 --> 00:29:17.590
monitors it's going to run.
00:29:17.590 --> 00:29:22.780
And then push back events and data
and state to the management server.
00:29:24.580 --> 00:29:27.800
So this is a little different for
UNIX and Linux.
00:29:27.800 --> 00:29:31.720
The agent for UNIX and Linux is
a much lighter weight agent,
00:29:31.720 --> 00:29:35.130
whereas we have a full or
fat agent on the Windows computer.
00:29:35.130 --> 00:29:38.025
A very lightweight agent on
the UNIX or Linux computer.
00:29:38.025 --> 00:29:43.680
In fact, it's very similar to just
what you have in Windows in WMI.
00:29:43.680 --> 00:29:44.750
It is a SIM server.
00:29:46.020 --> 00:29:50.010
Same OMI that Eric talked
about with ConfigMgr.
00:29:50.010 --> 00:29:54.532
And then a set of providers that
enumerate data around length of
00:29:54.532 --> 00:29:59.670
running processes and processor
performance and memory statistics.
00:29:59.670 --> 00:30:03.671
There are two kind of key
protocols that are used here.
00:30:03.671 --> 00:30:07.500
We're talking from the management
server to the Unix and
00:30:07.500 --> 00:30:08.705
Linux computer.
00:30:08.705 --> 00:30:11.423
Firstly, from agent
maintenance only for
00:30:11.423 --> 00:30:15.049
when we need to install the agent,
uninstall the agent,
00:30:15.049 --> 00:30:18.750
upgrade the agent,
using the PowerShell commandments or
00:30:18.750 --> 00:30:23.451
discovery wizard or upgrade wizard
that are part of operations manager.
00:30:24.520 --> 00:30:25.820
Number SSH.
00:30:27.360 --> 00:30:28.610
Kind of obvious why we need that,
00:30:28.610 --> 00:30:30.460
because we need,
we're not sure that.
00:30:30.460 --> 00:30:33.266
We can't talk to out agent,
if we're installing it or
00:30:33.266 --> 00:30:35.040
uninstalling it or upgrading it.
00:30:35.040 --> 00:30:39.208
For those SSH connections,
we support SSH key authentications,
00:30:39.208 --> 00:30:42.120
pseudo-elevations, pseudo-elevation.
00:30:42.120 --> 00:30:45.278
Pretty much every one of those
actions done over SSH is
00:30:45.278 --> 00:30:46.620
a privileged action.
00:30:46.620 --> 00:30:51.588
We're talking about installing and
uninstalling packages,
00:30:51.588 --> 00:30:53.000
all monitoring.
00:30:53.000 --> 00:30:56.906
Everything other than administering
the agent itself is done over
00:30:56.906 --> 00:31:00.750
the WS-Man protocol or
the Web Service-Management protocol.
00:31:00.750 --> 00:31:07.017
This is a standard SOAP-based
web service protocol for
00:31:07.017 --> 00:31:11.291
doing management of the SIM servers.
00:31:11.291 --> 00:31:14.872
So the key difference here
is that for Unix and Linux,
00:31:14.872 --> 00:31:16.544
the management server,
00:31:16.544 --> 00:31:21.250
Windows Server is the health service
for the Unix and Linux computer.
00:31:21.250 --> 00:31:24.670
It does a lot more of that
processing in a centralized fashion.
00:31:24.670 --> 00:31:28.632
You have a lighter-weight
agent on the Unix and
00:31:28.632 --> 00:31:31.800
Linux box and
that may come into play,
00:31:31.800 --> 00:31:36.870
if you're troubleshooting
Discovery or things like that.
00:31:36.870 --> 00:31:40.416
Once we get beyond that and
into the management packs,
00:31:40.416 --> 00:31:44.966
there's a lot of similarity between
the management packs for Unix and
00:31:44.966 --> 00:31:46.290
Linux and Windows.
00:31:46.290 --> 00:31:52.230
We've been iterating on kind of
the same base operating system
00:31:52.230 --> 00:31:57.960
management packs for Unix and
Linux for about six years now.
00:31:57.960 --> 00:32:01.536
So we feel pretty good about
the kind of coverage we have
00:32:01.536 --> 00:32:05.210
out of the box for your Unix and
Linux operating system.
00:32:05.210 --> 00:32:08.907
CPU performance metrics,
memory statistics,
00:32:08.907 --> 00:32:11.710
disk statistics and availability.
00:32:11.710 --> 00:32:14.615
Looking for things,
like free space and
00:32:14.615 --> 00:32:19.750
inodes as well as disk performance
and network statistics we collect.
00:32:19.750 --> 00:32:22.382
We have some out of
the box monitors for
00:32:22.382 --> 00:32:26.167
essential daemons on your Unix and
Linux computers and
00:32:26.167 --> 00:32:30.540
then we'll look at how you can
customize process monitoring.
00:32:30.540 --> 00:32:33.600
And likewise with log files,
we look for
00:32:33.600 --> 00:32:38.280
some key kind of security related
events in the system logs and
00:32:38.280 --> 00:32:42.510
then it's fairly easy
to customize that.
00:32:42.510 --> 00:32:45.460
So pretty good coverage of
that core operating system.
00:32:46.490 --> 00:32:49.670
Unfortunately, that's usually
not enough for monitoring.
00:32:49.670 --> 00:32:54.363
We might wanna know about higher
level services than the operating
00:32:54.363 --> 00:32:55.536
system itself,
00:32:55.536 --> 00:33:00.250
unless we're just running operating
systems in our datacenter.
00:33:00.250 --> 00:33:04.331
Key area of extensibility
with Ops Manager for Unix and
00:33:04.331 --> 00:33:07.470
Linux is through these template.
00:33:07.470 --> 00:33:09.710
If you've been working
with Ops Manager and
00:33:09.710 --> 00:33:11.910
you've done some management
kind of authoring,
00:33:11.910 --> 00:33:14.690
you can do a lot with
managing pack authoring.
00:33:14.690 --> 00:33:18.476
The point of these templates
is to make common,
00:33:18.476 --> 00:33:23.790
easy customizations very accessible,
very rapid to implement.
00:33:23.790 --> 00:33:26.993
You can absolutely dig
a lot deeper once you start
00:33:26.993 --> 00:33:30.277
working with managing packs and
Visual Studio and
00:33:30.277 --> 00:33:33.420
stuff like that and
the templates themselves.
00:33:33.420 --> 00:33:36.650
Log file,
said give us the path to a log file,
00:33:36.650 --> 00:33:39.460
give us a regular
expression pattern.
00:33:39.460 --> 00:33:44.091
We'll scan that periodically and
then alert if we match lines in
00:33:44.091 --> 00:33:47.790
that, if that regular
expression matches lines.
00:33:47.790 --> 00:33:51.587
Process monitoring,
give us the name of a process,
00:33:51.587 --> 00:33:55.731
tell us how many minimum and
maximum should be running and
00:33:55.731 --> 00:33:59.290
then will alert if you
exceed those boundaries.
00:33:59.290 --> 00:34:03.856
Back in 2007 R2 before
we added this feature,
00:34:03.856 --> 00:34:09.920
we used to have a lot of customers
who said, hey, what do I do about?
00:34:09.920 --> 00:34:13.315
I've got ten Java processes and
only one maps to this specific
00:34:13.315 --> 00:34:16.490
application, I want
different alerts.
00:34:16.490 --> 00:34:18.020
So we did add the ability to
00:34:19.050 --> 00:34:23.190
filter that process monitoring
by the arguments to the process.
00:34:23.190 --> 00:34:27.430
So you can distinguish when you have
multiple processes of the same name
00:34:27.430 --> 00:34:29.340
that actually represent
different applications.
00:34:30.890 --> 00:34:34.340
So those two process monitoring,
long file monitoring, that gives you
00:34:34.340 --> 00:34:38.710
a pretty good minimum viable
monitoring for an application.
00:34:39.840 --> 00:34:44.780
We hear a lot from customers who
have invested a lot of their
00:34:44.780 --> 00:34:48.490
operational intellectual
property into shell scripts.
00:34:48.490 --> 00:34:51.872
Over the years, monitoring
tools may have come and gone,
00:34:51.872 --> 00:34:53.540
those scripts have stayed.
00:34:53.540 --> 00:34:57.705
Those are super easy to plugin to
Office manager with these shell
00:34:57.705 --> 00:35:02.025
command templates like build
a monitor or performance collection
00:35:02.025 --> 00:35:05.802
rule and alerting rule by
running any arbitrary command,
00:35:05.802 --> 00:35:09.830
which could be a script in the file
system, a shell one liner.
00:35:14.120 --> 00:35:18.805
With the 2012 release,
we also made our first foray
00:35:18.805 --> 00:35:23.491
into actual applications
management packs for Unix and
00:35:23.491 --> 00:35:27.290
Linux with
JEE AppServer Management Packs.
00:35:27.290 --> 00:35:31.870
These support Tomcat and
JBoss and WebSphere and WebLogic.
00:35:31.870 --> 00:35:36.385
I will find your JEE op
servers on Windows or Unix or
00:35:36.385 --> 00:35:42.420
Linux computers, then we have
an open source application.
00:35:42.420 --> 00:35:48.080
A servlet called Bean Spy, that is
effectively an interface to JMX.
00:35:48.080 --> 00:35:53.414
The MBean store and that corresponds
to a template implementation
00:35:53.414 --> 00:35:58.940
operations manager, it allows you
very easily to get properties and
00:35:58.940 --> 00:36:04.860
methods in your JMX implementation
into ops manager rules and monitors.
00:36:05.920 --> 00:36:08.370
So out of the box,
we're gonna give you some key
00:36:08.370 --> 00:36:13.610
performance metrics around memory
heaps and garbage collection.
00:36:13.610 --> 00:36:17.500
But then if you're instrumenting
your Java applications in JMX,
00:36:17.500 --> 00:36:20.950
it's very easy to bring that
into ops manager monitoring.
00:36:22.490 --> 00:36:24.780
So I should probably pause here for
00:36:24.780 --> 00:36:29.430
a second and point out that in
a session tomorrow morning,,
00:36:29.430 --> 00:36:33.079
we're gonna be talking about new
features for System Center 2016.
00:36:34.320 --> 00:36:38.720
Where we will introduce really
building on this management packs
00:36:38.720 --> 00:36:42.080
monitoring for
open source applications theme.
00:36:42.080 --> 00:36:45.120
So be sure,
if you can check that out.
00:36:45.120 --> 00:36:47.990
If not,
catch the video after the fact.
00:36:47.990 --> 00:36:51.470
We'll be talking more about what
we're doing with management packs
00:36:51.470 --> 00:36:52.915
for the application space.
00:36:55.500 --> 00:36:58.219
If you've walked the expo halls,
00:36:58.219 --> 00:37:01.499
you might have seen
some of our partners,
00:37:01.499 --> 00:37:07.045
particularly around commercial
applications like Oracle and DV2.
00:37:07.045 --> 00:37:08.875
We have a really good
partner ecosystem.
00:37:08.875 --> 00:37:12.932
There are three partners down at
the floor of the Expo Hall that have
00:37:12.932 --> 00:37:15.910
really good Oracle
database management packs.
00:37:15.910 --> 00:37:21.016
That's when it's a little complex to
try to build yourself, we definitely
00:37:21.016 --> 00:37:25.325
for something like that would
steer you towards our partners and
00:37:25.325 --> 00:37:29.337
I think all of these are actually
at the Expo Hall this week.
00:37:34.500 --> 00:37:38.960
Let's have a look here
at operations manager.
00:37:46.710 --> 00:37:50.620
So we are looking at a dashboard
of some Unix and Linux computers.
00:37:56.700 --> 00:38:01.960
And I can jump over to a state
view of Unix and Linux computers.
00:38:01.960 --> 00:38:05.946
These happen to all be Linux
computers running in my lab
00:38:05.946 --> 00:38:07.080
environment.
00:38:07.080 --> 00:38:11.705
Again, if you've not used Unix and
Linux ops manager at this point in
00:38:11.705 --> 00:38:15.710
the console, it's gonna look
very much like for Windows.
00:38:18.370 --> 00:38:20.990
I can open up the Help Explorer.
00:38:24.670 --> 00:38:31.250
Let me drill in and see what we're
looking at here for monitoring.
00:38:31.250 --> 00:38:35.168
So we've got monitoring
on our file systems,
00:38:35.168 --> 00:38:39.290
we'll do some monitoring for
the agent itself.
00:38:39.290 --> 00:38:42.007
Some heartbeat monitoring,
you can, if you want,
00:38:42.007 --> 00:38:44.370
you can use that as an up
down monitor as well.
00:38:44.370 --> 00:38:48.418
It will alert you if
the agent is not responsive,
00:38:48.418 --> 00:38:53.456
which would also apply if
the machine were not responsive and
00:38:53.456 --> 00:38:58.920
do some performance monitoring for
SWAP and processor metrics.
00:39:04.794 --> 00:39:06.664
We can of course, look at processes.
00:39:06.664 --> 00:39:08.754
Like this one is looking at SSHD.
00:39:11.044 --> 00:39:14.076
We've done a lot over the years
to actually really try to build
00:39:14.076 --> 00:39:16.540
out our knowledge articles
that display in here.
00:39:16.540 --> 00:39:20.938
Try to give some good
explanations of how those metrics
00:39:20.938 --> 00:39:26.210
are calculated and what could
potentially cause an issue there.
00:39:30.040 --> 00:39:33.460
Additionally, we have a couple
tasks that we ship out of the box.
00:39:33.460 --> 00:39:37.439
So if you're investigating
a performance issue and
00:39:37.439 --> 00:39:39.518
maybe you wanna hop over and
00:39:39.518 --> 00:39:43.870
see what top ten CPU consumers
now are running on the box.
00:39:43.870 --> 00:39:49.934
And this is actually running like
a SIM method and location out to
00:39:49.934 --> 00:39:56.010
the box to get a real time picture
of process consumption of CPU.
00:39:56.010 --> 00:39:59.955
And of course,
because it's operations manager,
00:39:59.955 --> 00:40:02.470
we take a model view of the world.
00:40:02.470 --> 00:40:04.510
And so
we can jump into the diagram view.
00:40:09.270 --> 00:40:12.010
And see all the assets that
are discovered on this box.
00:40:12.010 --> 00:40:15.407
So here's our operating system,
our network adapter,
00:40:15.407 --> 00:40:19.309
our file system, and would collect
some data about what that is.
00:40:21.360 --> 00:40:25.850
For each of the operating systems we
believe, I think, we ship like 10 or
00:40:25.850 --> 00:40:26.650
12 reports.
00:40:27.690 --> 00:40:31.970
We kinda overhauled these back
in the 2012 release to be
00:40:31.970 --> 00:40:37.430
a little more targeted to Linux and
UNIX.
00:40:37.430 --> 00:40:41.580
So we can jump into like
the performance history report
00:40:41.580 --> 00:40:42.260
for a machine.
00:40:42.260 --> 00:40:45.430
And again,
this is all SQL reporting,
00:40:45.430 --> 00:40:49.130
like much of the rest
of the system center.
00:40:49.130 --> 00:40:53.090
Any custom rules that you add for
performance collection, if
00:40:53.090 --> 00:40:56.850
you're using a shelf command, those
all go into the data warehouse.
00:40:56.850 --> 00:40:59.864
And there are some generic
reports right in the console, and
00:40:59.864 --> 00:41:01.660
you can get a report on those.
00:41:01.660 --> 00:41:04.730
So if you do your own custom
management packs here and
00:41:04.730 --> 00:41:09.630
shell command templates,
you can build reports on those.
00:41:09.630 --> 00:41:10.950
Schedule them, etcetera.
00:41:10.950 --> 00:41:13.460
I'm going to run this.
00:41:13.460 --> 00:41:18.307
This should give us a overview here.
00:41:30.125 --> 00:41:32.320
All right, looks like it wrapped up.
00:41:33.780 --> 00:41:36.540
And at first, it's SSRS,
so we could schedule this,
00:41:36.540 --> 00:41:39.606
we could subscribe to it,
we could save it to our workspace.
00:41:44.343 --> 00:41:45.913
And in a similar vein,
00:41:45.913 --> 00:41:49.640
we have a number of performance
views in the console.
00:41:50.850 --> 00:41:54.690
So if I wanted to jump in and just
look for a performance metric on
00:41:54.690 --> 00:41:59.990
swap space and
jump into this performance,
00:41:59.990 --> 00:42:05.570
you search for it, pick the machine,
and set my time range.
00:42:05.570 --> 00:42:10.980
Maybe I want to look just for today.
00:42:10.980 --> 00:42:14.020
And then we ship a number of,
in those core management packs
00:42:14.020 --> 00:42:17.590
the number of views for
this dash board views.
00:42:17.590 --> 00:42:19.940
So if you wanna load
up these charts and
00:42:19.940 --> 00:42:24.370
really focus on a particular
performance area for your machines.
00:42:24.370 --> 00:42:27.720
Of course, all the dash boarding
investments that have gone into
00:42:27.720 --> 00:42:32.290
ops manager over the years, the past
few years are viable for Linux and
00:42:32.290 --> 00:42:33.000
UNIX, as well.
00:42:34.710 --> 00:42:38.560
So, let's move over to
some customization.
00:42:40.450 --> 00:42:45.324
They talked about there's
three templates we have in
00:42:45.324 --> 00:42:48.148
Office Manager 2012 R2.
00:42:48.148 --> 00:42:53.302
We can start by looking at
the process monitoring template.
00:42:58.341 --> 00:43:02.408
And let's say I've got a Linux DNS
server running bind, and
00:43:02.408 --> 00:43:06.700
I wanna know that main D
is always up and available.
00:43:06.700 --> 00:43:08.040
I can create a template.
00:43:08.040 --> 00:43:10.670
It's called like Linux DNS daemon.
00:43:12.670 --> 00:43:16.519
Before the conference, say I created
a management pack and a group.
00:43:19.329 --> 00:43:22.852
Now with this process template,
I could just go in and
00:43:22.852 --> 00:43:27.370
actually narrow binds daemon
as name D, but maybe I don't.
00:43:27.370 --> 00:43:29.350
Not quite sure.
00:43:29.350 --> 00:43:33.950
Can never really remember which
distros name Apache HTTPD and
00:43:33.950 --> 00:43:35.270
which name of Apache two.
00:43:37.050 --> 00:43:42.030
So I can browse out to the machine
and actually find my daemon.
00:43:42.030 --> 00:43:42.659
Select it.
00:43:43.830 --> 00:43:47.360
And this is where I would, if I had
multiple processes with the same
00:43:47.360 --> 00:43:50.060
name, I would provide my regular
expression to filter that.
00:43:51.520 --> 00:43:57.448
In this case, I wanna actually,
let's target a group that I created.
00:44:01.349 --> 00:44:07.190
So any Linux servers in that group
will get this process monitoring for
00:44:07.190 --> 00:44:08.477
name D daemon.
00:44:10.636 --> 00:44:14.596
And again, minimum, maximum number
of processes you can pretty
00:44:14.596 --> 00:44:17.556
much get to whatever you
need on that threshold.
00:44:30.489 --> 00:44:31.951
All right.
00:44:31.951 --> 00:44:34.820
Long File template is
really quite similar.
00:44:34.820 --> 00:44:37.939
I'll just show what this looks like.
00:44:49.247 --> 00:44:52.846
So, again, we will just go into
the template wizard, provide a name.
00:44:56.862 --> 00:44:58.356
Put in our management pack,
00:44:58.356 --> 00:45:02.030
we can use those management to move
things out of our dev environment,
00:45:02.030 --> 00:45:06.200
into our test environment,
into our production environment.
00:45:06.200 --> 00:45:08.029
I can pick a computer group.
00:45:14.298 --> 00:45:18.590
Provide a path, and
then our regular expression.
00:45:19.740 --> 00:45:21.810
So, pretty straightforward, but
00:45:21.810 --> 00:45:26.980
ultimately quite an essential
bit of customization.
00:45:26.980 --> 00:45:31.660
And so we did our process monitoring
template, to monitor our DNS server.
00:45:31.660 --> 00:45:34.850
You know that's a pretty good
start for monitoring that our DNS
00:45:34.850 --> 00:45:38.010
server is working,
if the process is actually running,
00:45:38.010 --> 00:45:40.910
doesn't quite give us everything
that we would need to know.
00:45:40.910 --> 00:45:43.300
Maybe I'm concerned that my
00:45:43.300 --> 00:45:46.590
DNS server can't resolve
public addresses.
00:45:47.640 --> 00:45:54.080
With the shell command,
like say dig,
00:45:54.080 --> 00:45:59.130
against the local host to
resolve a public address, and
00:45:59.130 --> 00:46:03.550
then use grep and wc -l and
get a numeric status
00:46:03.550 --> 00:46:06.640
value based on whether my
dig command worked or not.
00:46:06.640 --> 00:46:09.880
Ultimately, this is a one line
command that'll tell me if my local
00:46:09.880 --> 00:46:13.510
DNS server, can actually
resolve a public address.
00:46:14.560 --> 00:46:17.054
See if I wanted to build
a monitor on that,
00:46:17.054 --> 00:46:19.919
I would simply come in to
create a unit monitor.
00:46:24.168 --> 00:46:27.767
Pick shelled command
two state monitor.
00:46:30.948 --> 00:46:34.222
I'll keep going with
this management pack.
00:46:34.222 --> 00:46:35.035
Let's say.
00:46:35.035 --> 00:46:37.408
Test DNS found.
00:46:37.408 --> 00:46:39.020
Give the monitor a name.
00:46:40.580 --> 00:46:42.128
Select my target.
00:46:47.120 --> 00:46:50.220
Say check this every five minutes.
00:46:50.220 --> 00:46:52.160
I simply paste my command in there.
00:46:52.160 --> 00:46:54.520
This command doesn't
require any privileges.
00:46:54.520 --> 00:46:58.014
I could select my privilege account
that will allow me to use sudo -l
00:46:58.014 --> 00:47:00.330
authorization to do something.
00:47:00.330 --> 00:47:06.410
They required actual privileges,
like if I wanted to run
00:47:06.410 --> 00:47:10.390
a cluster monitoring command like
clustat that requires privileges.
00:47:10.390 --> 00:47:11.890
And I had to authorize
that with sudo.
00:47:14.290 --> 00:47:16.780
So we build our actual expressions.
00:47:16.780 --> 00:47:17.880
This should be very familiar,
00:47:17.880 --> 00:47:21.360
if you've done some templates
in the operations manager.
00:47:22.420 --> 00:47:27.270
So we'll say we are,
thinking about those,
00:47:27.270 --> 00:47:31.290
unhealthy if our output
does not equal one.
00:47:31.290 --> 00:47:38.595
And healthy if our
standard out equals one.
00:47:41.475 --> 00:47:42.798
You can set a severity.
00:47:45.863 --> 00:47:49.607
And then generate,
specify our alert text, and
00:47:49.607 --> 00:47:53.090
of course we can drop
in the target variable.
00:47:53.090 --> 00:47:59.210
So, let's drop in our host
name of the UNIX computer and
00:47:59.210 --> 00:48:01.410
then let's put in the output
from our command.
00:48:03.300 --> 00:48:06.250
So we've got a one line command.
00:48:06.250 --> 00:48:08.630
We have a script we can call and
get some output,
00:48:08.630 --> 00:48:11.110
really easy to bring
that into monitoring.
00:48:11.110 --> 00:48:17.080
There's, again, an alert collection
rule, a performance collection rule,
00:48:17.080 --> 00:48:22.018
that allow you to uses the same UI,
the same kind of capabilities.
00:48:25.060 --> 00:48:27.799
Let's jump back to
this slide back here.
00:48:32.652 --> 00:48:35.107
So anyone worked with DSC before,
00:48:35.107 --> 00:48:38.830
PowerShell Desired
State Configuration?
00:48:38.830 --> 00:48:43.140
This is actually a new capability
for Linux, it was new for
00:48:43.140 --> 00:48:44.830
Windows in 2012 R2.
00:48:44.830 --> 00:48:48.280
We just released this for
Linux earlier this week.
00:48:48.280 --> 00:48:52.290
It's not actually a system
centered technology.
00:48:52.290 --> 00:48:55.030
It's a feature of PowerShell,
but I think you'll
00:48:55.030 --> 00:48:59.270
see how well it integrates with
this Linux management environment.
00:48:59.270 --> 00:49:02.000
For those of you
unfamiliar with DSC this
00:49:02.000 --> 00:49:05.490
is just generally PowerShell
desired state configuration.
00:49:05.490 --> 00:49:08.260
This is a declarative
configuration platform.
00:49:08.260 --> 00:49:10.840
You can define a configuration,
00:49:10.840 --> 00:49:15.430
set this file with these
contents at this location,
00:49:15.430 --> 00:49:19.645
make sure it exists, and then leave
it up to DSC to make that happen.
00:49:19.645 --> 00:49:21.930
Doesnt' matter what
the state was before,
00:49:21.930 --> 00:49:24.690
DSC's going to get
it into that state.
00:49:24.690 --> 00:49:27.530
This can be used to protect
against configuration drift.
00:49:27.530 --> 00:49:32.120
We can have a DSC agent
reapplying its configuration.
00:49:32.120 --> 00:49:36.340
So if you set an ACL on a file
with DSC, someone changed that,
00:49:36.340 --> 00:49:37.389
DSC will set it back.
00:49:38.850 --> 00:49:41.220
And DSC is a little
unique in this space.
00:49:41.220 --> 00:49:42.910
It's all standard's based.
00:49:42.910 --> 00:49:46.500
The actual configuration
documents are mof documents.
00:49:46.500 --> 00:49:49.028
Communication protocols are,
again, WSMan.
00:49:50.505 --> 00:49:54.086
So with DSC for Linux,
again, this is using OMI,
00:49:54.086 --> 00:49:58.608
similar to our CM and Office Manager
agents for UNIX and Linux,
00:49:58.608 --> 00:50:02.295
same kinda Linux support
matrix that we've seen.
00:50:02.295 --> 00:50:07.975
Was open sourced on GitHub.
00:50:07.975 --> 00:50:12.062
What we've done for DSC for Linux is
we've ported the aging component,
00:50:12.062 --> 00:50:16.140
the local configuration manager,
which was actually written in C.
00:50:16.140 --> 00:50:19.280
It was designed to run with
Windows and Linux, but
00:50:19.280 --> 00:50:22.210
we've ported that over to Linux and
made sure that it worked.
00:50:23.320 --> 00:50:25.610
And that's an actually,
an online provider.
00:50:25.610 --> 00:50:29.010
And then it has a set
of resource providers.
00:50:29.010 --> 00:50:32.160
These do things like manage
archive files and files and
00:50:32.160 --> 00:50:37.670
the lines within a file, which is
actually really critical in Linux.
00:50:37.670 --> 00:50:42.510
Packages, so we can say define
in the configuration that these
00:50:42.510 --> 00:50:45.620
packages should be present,
these should not be present.
00:50:45.620 --> 00:50:48.210
Users, and groups, and
scripts, and services.
00:50:50.680 --> 00:50:52.634
And we support things
like pull servers for
00:50:52.634 --> 00:50:54.810
centralized distribution
of configuration.
00:50:56.824 --> 00:51:00.025
If you've not seen the DSC
configuration before,
00:51:00.025 --> 00:51:02.300
it's actually pretty readable.
00:51:02.300 --> 00:51:06.260
So, this is an example
configuration that would,
00:51:06.260 --> 00:51:08.880
if applied to a Linux
computer it makes
00:51:08.880 --> 00:51:13.400
sure that httpd in mod is a self
package where it installed and
00:51:13.400 --> 00:51:17.240
that the apache service is
running and enable to unboot.
00:51:17.240 --> 00:51:19.980
And this would be in power cell.
00:51:19.980 --> 00:51:23.470
I would actually run that,
it would generate a moth document.
00:51:25.000 --> 00:51:26.880
This is standard document.
00:51:26.880 --> 00:51:30.718
Describing the configuration that
moth could be pushed out over a sim
00:51:30.718 --> 00:51:34.689
session to the Linux computer, or it
could be distributed on my central
00:51:34.689 --> 00:51:37.468
pulse server that I've
registered on my Linux and
00:51:37.468 --> 00:51:40.669
Windows computers to go pull
down configurations from.
00:51:45.667 --> 00:51:48.980
So let's look at this in
our demo environment.
00:51:53.794 --> 00:51:58.860
And there are a number of kind of
key scenarios that DSE's useful for.
00:52:00.870 --> 00:52:04.220
I'll in fact, in our session
tomorrow morning, I'll kind of look
00:52:04.220 --> 00:52:08.759
at, do a demonstration of using DSE
as a continuous deployment scenario,
00:52:08.759 --> 00:52:10.650
so dropping a web app on a share and
00:52:10.650 --> 00:52:12.410
distributing that out
to your web servers.
00:52:12.410 --> 00:52:16.860
In this case, we'll be looking at
it more as like a VM provisioning.
00:52:16.860 --> 00:52:22.260
So I mentioned earlier with our VM
templates that we were bootstrapping
00:52:22.260 --> 00:52:25.550
the DSC agent by installing it
with those run once commands.
00:52:27.090 --> 00:52:33.360
So it actually deployed that
out through the Azure Pack.
00:52:34.470 --> 00:52:38.700
I have Azure Pack configured
to kick off an SMA run book
00:52:38.700 --> 00:52:40.760
whenever a VM is deployed.
00:52:40.760 --> 00:52:44.910
That SMA run book grabs data
out of the template deployment,
00:52:44.910 --> 00:52:46.940
like the operating system.
00:52:46.940 --> 00:52:48.830
And passes it off
to another run book
00:52:50.600 --> 00:52:52.520
that actually is just a DSC script.
00:52:56.980 --> 00:53:00.390
So if you recall our slide earlier
that had some example script,
00:53:00.390 --> 00:53:02.800
you'll see some similar syntax here.
00:53:02.800 --> 00:53:06.010
And for
those of you who've worked with
00:53:06.010 --> 00:53:09.680
system center operations manager
Unix and Linux, you know there
00:53:09.680 --> 00:53:13.570
are some things we need to set up on
our Linux box before we discover it.
00:53:13.570 --> 00:53:15.550
And set up some
pseudo authorization,
00:53:15.550 --> 00:53:20.380
we need to make sure that our
user accounts are configured,
00:53:20.380 --> 00:53:22.580
that we've got good
name resolution going.
00:53:23.820 --> 00:53:27.110
So I've simply automated all of
those configurations, the user
00:53:27.110 --> 00:53:32.970
creation, the home directory for
that user, pseudo configuration.
00:53:32.970 --> 00:53:38.570
Set an authorize key for my user,
or in management, a resolv.conf.
00:53:38.570 --> 00:53:40.670
That's all scripted out in
this estimate run book,
00:53:40.670 --> 00:53:43.460
which is applied to
the VM automatically.
00:53:44.730 --> 00:53:49.670
And if I jump back to my automation
jobs, with any luck that actually
00:53:49.670 --> 00:53:52.740
worked on our deployment from
earlier in this session.
00:53:55.470 --> 00:53:58.180
Looking at scrub logs is
such an exciting demo.
00:53:58.180 --> 00:54:04.851
But in theory, oh that failed.
00:54:04.851 --> 00:54:09.442
Looks like a name
resolution problem.
00:54:09.442 --> 00:54:11.290
Yep.
00:54:11.290 --> 00:54:17.222
I got reverse lookup,
I did one earlier just in case.
00:54:17.222 --> 00:54:18.623
All right.
00:54:18.623 --> 00:54:22.486
So from the deployment
I ran this morning,
00:54:22.486 --> 00:54:26.040
I actually apply that configuration.
00:54:26.040 --> 00:54:29.480
I also used estimated deploy
the ops manager agent.
00:54:29.480 --> 00:54:32.480
The DSC configuration
deployed the CM agent.
00:54:32.480 --> 00:54:37.880
This is roll, demo one.
00:54:37.880 --> 00:54:42.710
That should've shown
up in Office Manager.
00:54:44.410 --> 00:54:47.190
So, of course we can keep
reapplying that configuration.
00:54:47.190 --> 00:54:49.290
In fact, I have an SMA
run book that does that.
00:54:49.290 --> 00:54:51.780
We can also do that
through a poll server.
00:54:51.780 --> 00:54:54.430
So, if you're using Powershell
as an automation platform,
00:54:56.120 --> 00:54:58.510
definitely check out DSC for Linux.
00:55:00.620 --> 00:55:02.280
It's super useful.
00:55:02.280 --> 00:55:04.979
And again,
if you're using Chef or Puppet,
00:55:04.979 --> 00:55:08.176
that same kind of approach
of bootstrapping in VMM and
00:55:08.176 --> 00:55:10.889
integrating it there
is definitely viable.
00:55:17.555 --> 00:55:21.349
So, I do hope that we've conveyed
the message to you that we're
00:55:21.349 --> 00:55:24.190
absolutely serious about this.
00:55:24.190 --> 00:55:25.620
Our team is growing.
00:55:25.620 --> 00:55:28.620
The feature areas we're
working on are increasing.
00:55:29.720 --> 00:55:32.880
The pace at which we're doing
Linux features is increasing.
00:55:32.880 --> 00:55:35.390
And we've been doing this for
a while.
00:55:35.390 --> 00:55:37.970
We have a lot of machines in
00:55:37.970 --> 00:55:41.810
production environments managed
with System Center today, Unix and
00:55:41.810 --> 00:55:44.600
Linux machines managed
with System Center today.
00:55:44.600 --> 00:55:49.820
And this is something that
you will see Microsoft,
00:55:49.820 --> 00:55:52.969
as a company, investments in
Linux continue to increase
00:55:54.960 --> 00:55:59.580
going as you have over
the past few months.
00:55:59.580 --> 00:56:04.160
All right, so assume everyone
has seen some of these slides.
00:56:04.160 --> 00:56:08.181
It's the first time I've seen it.
00:56:08.181 --> 00:56:09.400
All right.
00:56:09.400 --> 00:56:14.640
I encourage you to
finish your evaluations.
00:56:14.640 --> 00:56:16.630
I'm happy that we have some time.
00:56:16.630 --> 00:56:18.025
So I'm happy to take questions.
00:56:30.864 --> 00:56:33.984
We will be hanging out out here for
a bit too if you want to ask
00:56:33.984 --> 00:56:37.160
a question directly to us or
the product team.
00:56:37.160 --> 00:56:39.160
And then I think we'll probably
be back in the booth for
00:56:39.160 --> 00:56:40.900
a bit the remainder
of the afternoon.
00:56:42.700 --> 00:56:45.053
Any other questions before
we step off the stage?
00:56:48.405 --> 00:56:49.570
>> Yes, no, no questions?
00:56:49.570 --> 00:56:51.420
>> All right, well thanks everyone.
00:56:51.420 --> 00:56:51.995
>> Yeah, thank you.
00:56:51.995 --> 00:56:55.910
>> [APPLAUSE]