WEBVTT

00:00:00.000 --> 00:00:01.740
>> Ciao il mio nome è Thomas Maurer.

00:00:01.740 --> 00:00:04.770
Sono un Sostenitore Cloud presso Microsoft
e sono seduto qui con

00:00:04.770 --> 00:00:06.645
Chang' dal team di gestione di Azure

00:00:06.645 --> 00:00:08.635
per parlare di ibrido
Gestione server.

00:00:08.635 --> 00:00:11.300
>> sì. ciao. Sono un
Program Manager in Azure.

00:00:11.300 --> 00:00:14.100
>> Ciao. Così parlo molto con

00:00:14.100 --> 00:00:17.925
clienti che utilizzano il
Cloud per le risorse di elaborazione.

00:00:17.925 --> 00:00:20.610
Ma la maggior parte di loro o un
molti di loro hanno anche

00:00:20.610 --> 00:00:22.950
server in esecuzione nel loro
data center privati,

00:00:22.950 --> 00:00:24.495
nelle loro succursali,

00:00:24.495 --> 00:00:26.910
o anche avere altre parti in
l'organizzazione che

00:00:26.910 --> 00:00:30.195
utilizzare un altro provider cloud o
un altro fornitore di servizi.

00:00:30.195 --> 00:00:31.830
Una delle principali sfide con

00:00:31.830 --> 00:00:34.490
tutti questi server che
hanno è fondamentalmente mantenere

00:00:34.490 --> 00:00:36.400
controllo di tutti questi
server ogni volta che sono

00:00:36.400 --> 00:00:38.620
in esecuzione per assicurarsi
che sono sicuri,

00:00:38.620 --> 00:00:42.085
che sono patch, che
hanno la conformità.

00:00:42.085 --> 00:00:44.585
Ho sentito che l'Azure
squadra e soprattutto si

00:00:44.585 --> 00:00:46.760
stanno lavorando su qualcosa
che aiuta con questo.

00:00:46.760 --> 00:00:49.940
>> sì. assolutamente
Mi piace parlare di

00:00:49.940 --> 00:00:53.240
e io stavo effettivamente riecheggiando
quello che hai appena detto.

00:00:53.240 --> 00:00:55.835
È davvero una sfida enorme.

00:00:55.835 --> 00:00:59.990
Così avevo parlato con un sacco di clienti
così soprattutto hanno bisogno

00:00:59.990 --> 00:01:03.890
per gestire questi molto simile
Ambienti ibridi,

00:01:03.890 --> 00:01:05.345
quindi siamo dappertutto

00:01:05.345 --> 00:01:07.490
con il team di applicazione
cercando di uscire,

00:01:07.490 --> 00:01:08.930
ottenere tutte le risorse di cui hanno bisogno.

00:01:08.930 --> 00:01:10.010
Non importa quale Cloud,

00:01:10.010 --> 00:01:12.845
basta andare in e
distribuire le cose lì.

00:01:12.845 --> 00:01:15.560
L'IT, d'altra parte, è
cercando di capire,

00:01:15.560 --> 00:01:17.540
oh mio Dio, dove sono tutte le cose?

00:01:17.540 --> 00:01:19.070
Dove sono tutti i dati?

00:01:19.070 --> 00:01:21.650
Cosa succede se
qualcosa è stato violato?

00:01:21.650 --> 00:01:24.545
Soprattutto ora si vede il
notizie in tutto il luogo.

00:01:24.545 --> 00:01:29.210
Quindi questo è davvero qualcosa
Azure ha sempre pensato

00:01:29.210 --> 00:01:31.760
circa e soprattutto i servizi

00:01:31.760 --> 00:01:34.970
oggi che già
gestione del servizio prem.

00:01:34.970 --> 00:01:36.470
Ma ora con questo servizio,

00:01:36.470 --> 00:01:39.620
lo stiamo davvero prendendo
al passo successivo per

00:01:39.620 --> 00:01:43.160
integrare tali server
in modo più nativo in Azure.

00:01:43.160 --> 00:01:44.975
>> Ok. Sembra fantastico.

00:01:44.975 --> 00:01:46.640
Così, quando si parla di integrare

00:01:46.640 --> 00:01:49.115
il servizio in Azure,
Cosa vuoi dire con questo?

00:01:49.115 --> 00:01:51.260
>> sì. Mi piace mostrare
una foto di esso.

00:01:51.260 --> 00:01:52.070
>> Perfetto. Grazie.

00:01:52.070 --> 00:01:56.630
>> Ecco come i servizi sono
gestione di questi ambienti.

00:01:56.630 --> 00:01:59.070
Quindi questi servizi in realtà,

00:01:59.070 --> 00:02:01.560
tutto il servizio gestito on-prem oggi.

00:02:01.560 --> 00:02:03.470
A proposito, sto chiamando
il server ponalm

00:02:03.470 --> 00:02:05.480
ma in realtà non
importa dove sono.

00:02:05.480 --> 00:02:07.400
Possono essere prem nei data center,

00:02:07.400 --> 00:02:10.580
data center privati, o in
altri host del Cloud.

00:02:10.580 --> 00:02:11.975
Ma come potete vedere,

00:02:11.975 --> 00:02:15.170
tutti questi server che gestiscono il
Macchine virtuali di Azure tramite

00:02:15.170 --> 00:02:18.515
il qualcosa chiamato Azure
Resource Manager, abbreviazione di ARM,

00:02:18.515 --> 00:02:21.305
e dove sui server locali,

00:02:21.305 --> 00:02:24.485
hanno davvero bisogno di capire
fuori un modo per ottenere il loro codice

00:02:24.485 --> 00:02:28.220
schierato su quelli on-prem
server singolarmente.

00:02:28.220 --> 00:02:29.840
Quindi, come potete vedere,

00:02:29.840 --> 00:02:32.180
c'è qualche disparità tra

00:02:32.180 --> 00:02:35.540
il pannello tubo e questo

00:02:35.540 --> 00:02:39.320
è davvero quello che intendo per nativamente
integrati nell'ARM.

00:02:39.320 --> 00:02:43.315
Ora vengono proiettati come
la risorsa ARM in Azure.

00:02:43.315 --> 00:02:45.295
Il vantaggio sarà enorme.

00:02:45.295 --> 00:02:48.220
Come potete vedere un sacco di
investimenti è andato in ARM;

00:02:48.220 --> 00:02:50.710
come l'identità, come
Controllo degli accessi in base al ruolo, ad esempio i criteri.

00:02:50.710 --> 00:02:53.170
La cosa più importante è che un sacco di
clienti si preoccupano davvero

00:02:53.170 --> 00:02:57.460
conformità e anche solo regolare
gestione come tag loro,

00:02:57.460 --> 00:02:59.800
mostrare quali sono i miei server
sono tutti in produzione,

00:02:59.800 --> 00:03:03.820
questo tipo di cose semplici
sono tutti capaci attraverso ARM.

00:03:03.820 --> 00:03:07.930
Così ora ho una volta progetto
questi server in ARM,

00:03:07.930 --> 00:03:09.520
Ottengo tutti questi benefici.

00:03:09.520 --> 00:03:12.160
Inoltre, tutte le
servizi ora possono essere

00:03:12.160 --> 00:03:16.725
distribuiti in Azure e
in loco nello stesso modo.

00:03:16.725 --> 00:03:18.000
Quindi, come potete vedere qui,

00:03:18.000 --> 00:03:22.805
Ho etichettato questo molto importante
componente denominato Agente guest.

00:03:22.805 --> 00:03:25.250
Lo scopo di questo
agente è quello di gestire

00:03:25.250 --> 00:03:28.430
il ciclo di vita di questi
estensioni e stiamo seguendo

00:03:28.430 --> 00:03:30.635
lo stesso modello in modo che ora

00:03:30.635 --> 00:03:34.630
tutte queste estensioni possono essere applicate
servizio on-prem pure.

00:03:34.630 --> 00:03:38.700
>> Quindi è fantastico. Così i nostri server
vengono visualizzate come risorse di Azure.

00:03:38.700 --> 00:03:41.480
Si presentano nel portale e anche
in Azure Resource Manager,

00:03:41.480 --> 00:03:44.330
e posso fondamentalmente trattare
come macchine,

00:03:44.330 --> 00:03:47.195
come ho usato per fare con Azure
Macchine virtuali, giusto?

00:03:47.195 --> 00:03:49.759
>> Sì. Da un
prospettiva gestionale,

00:03:49.759 --> 00:03:51.500
questo è il nostro obiettivo centrale.

00:03:51.500 --> 00:03:54.170
Volevamo tutti questi
soluzioni per gestire

00:03:54.170 --> 00:03:57.470
i server allo stesso modo
per Azure e

00:03:57.470 --> 00:04:03.805
per il pre-prem e anche
ottenere lo stesso vantaggio ARM.

00:04:03.805 --> 00:04:05.360
>> Ok, è fantastico.

00:04:05.360 --> 00:04:07.850
Quindi voglio ora usare che.

00:04:07.850 --> 00:04:11.215
Così si può mostrarmi come abbiamo
a bordo di questo servizio in Azure?

00:04:11.215 --> 00:04:13.460
>> Assolutamente, lasciate
mostrarvi una demo.

00:04:13.460 --> 00:04:15.560
Questa è una pagina che abbiamo costruito per mostrare

00:04:15.560 --> 00:04:19.960
tutti i server locali che
è stato on-boarded in Azure.

00:04:19.960 --> 00:04:23.890
Essenzialmente a bordo,
il cliente deve eseguire

00:04:23.890 --> 00:04:27.790
uno script sul server e per
contribuire a costruire quello script,

00:04:27.790 --> 00:04:32.840
in realtà costruiamo un flusso in
Azure per generare lo script.

00:04:33.260 --> 00:04:36.235
Quindi questa è l'opzione che possono

00:04:36.235 --> 00:04:39.100
fare clic per generare lo script
ma allo stesso tempo,

00:04:39.100 --> 00:04:42.520
riconosce anche è una sfida
per i clienti di on-board

00:04:42.520 --> 00:04:44.080
una scala se devono connettersi a

00:04:44.080 --> 00:04:46.705
ogni singolo server singolarmente
per eseguire questi script.

00:04:46.705 --> 00:04:49.240
Quindi stiamo anche cercando
per capire quali sono

00:04:49.240 --> 00:04:53.140
alcuni comuni server ponalm
applicazione di gestione in modo da poter

00:04:53.140 --> 00:04:57.505
integrarsi per aiutare i clienti a
a bordo di quelle macchine su larga scala.

00:04:57.505 --> 00:05:00.295
Ad esempio, qui, se
il server è già

00:05:00.295 --> 00:05:03.100
gestito dal servizio di aggiornamento di Azure,

00:05:03.100 --> 00:05:05.120
costruiamo in realtà lo script

00:05:05.120 --> 00:05:07.640
o i runbook per effettivamente
distribuire a bordo

00:05:07.640 --> 00:05:10.505
tali macchine in Azure

00:05:10.505 --> 00:05:13.055
senza in realtà i clienti
toccando tutte quelle macchine.

00:05:13.055 --> 00:05:15.770
Ma in futuro, siamo anche
lavorare con, ad esempio,

00:05:15.770 --> 00:05:19.129
System Center Configuration Manager
e stanno anche integrando

00:05:19.129 --> 00:05:20.870
l'esperienza di on-boarding e

00:05:20.870 --> 00:05:22.580
oltre all'interfaccia di amministrazione di Windows.

00:05:22.580 --> 00:05:25.850
Quindi abbiamo appena continuato
ampliando il modo in cui i clienti possono

00:05:25.850 --> 00:05:29.240
a bordo di Azure in
un modo meno sforzo.

00:05:29.240 --> 00:05:32.630
Ma in questo caso, lasciatemi mostrare
come generare lo script.

00:05:32.630 --> 00:05:35.510
Quindi, come potete vedere questi
sono risorse di Azure.Are Azure resources.

00:05:35.510 --> 00:05:37.220
Così seguono la stessa gerarchia

00:05:37.220 --> 00:05:39.140
come negli abbonamenti
e gruppo di risorse.

00:05:39.140 --> 00:05:40.385
Così ora si può scegliere

00:05:40.385 --> 00:05:44.870
quale sottoscrizione e risorsa
gruppo che volevano andare e qui

00:05:44.870 --> 00:05:46.790
la regione indica che

00:05:46.790 --> 00:05:48.950
quale area di Azure è in esecuzione

00:05:48.950 --> 00:05:51.980
questi server che gestiscono
queste risorse in loco.

00:05:51.980 --> 00:05:56.930
Così si può vedere dalla conformità
o prospettiva dei punti normativi,

00:05:56.930 --> 00:05:59.635
sappiamo dove i metadati
è archiviato in Azure.Is stored in Azure.

00:05:59.635 --> 00:06:03.620
La posizione fisica è nuova in modo specifico
per i server locali.

00:06:03.620 --> 00:06:06.245
Ciò consente al cliente di
per taggare i server

00:06:06.245 --> 00:06:10.655
o indicare in modo specifico
in quale data center si trovano.

00:06:10.655 --> 00:06:13.940
Si tratta in realtà di
facilità di gestione.

00:06:13.940 --> 00:06:15.440
>> Ok, questo è abbastanza fresco.

00:06:15.440 --> 00:06:18.650
Così i clienti non potevano solo aggiungere
un nome sopra i data center.

00:06:18.650 --> 00:06:20.330
Così potrebbero anche come, per esempio,

00:06:20.330 --> 00:06:22.460
anche aggiungere una stanza della posizione o

00:06:22.460 --> 00:06:25.520
anche il nome diretto o diretto
numero per il server?

00:06:25.520 --> 00:06:26.570
>> Sì, assolutamente.

00:06:26.570 --> 00:06:28.670
Quindi questo è davvero per il cliente

00:06:28.670 --> 00:06:31.100
per identificare facilmente
dove si trova tale risorsa.

00:06:31.100 --> 00:06:32.750
Se succede qualcosa a quel server,

00:06:32.750 --> 00:06:34.810
possono andare se hanno bisogno
per accedere fisicamente,

00:06:34.810 --> 00:06:37.160
sanno esattamente
dove devono essere.

00:06:37.160 --> 00:06:41.825
Qui permettiamo anche al cliente di
scegliere i sistemi operativi.

00:06:41.825 --> 00:06:45.200
Non ho davvero specificamente
esprimalo, ma come sempre,

00:06:45.200 --> 00:06:48.395
in Azure stiamo cercando di abbracciare
Windows così come Linux.

00:06:48.395 --> 00:06:50.570
Lo stesso per qui che costruiamo

00:06:50.570 --> 00:06:52.820
due pacchetti per l'agente di

00:06:52.820 --> 00:06:56.460
a bordo di Windows
Server Linux o Linux.

00:06:57.380 --> 00:07:01.200
Comprendere un sacco di clienti
soprattutto per il pre-prem,

00:07:01.200 --> 00:07:03.520
non vogliono
esporre i propri server a

00:07:03.520 --> 00:07:06.805
Internet direttamente e
metterlo dietro un server proxy.

00:07:06.805 --> 00:07:12.050
Quindi qui in questo caso il nostro agente
è necessario connettersi ad Azure.

00:07:14.280 --> 00:07:18.400
Se questi server non sono
connettersi direttamente ad Azure,

00:07:18.400 --> 00:07:21.610
possono configurare il
server proxy qui e poi

00:07:21.610 --> 00:07:26.000
l'agente sarà in grado di comunicare
tramite il server proxy.

00:07:26.880 --> 00:07:33.700
Questa è solo una risorsa di AzureThis is just an Azure resource
capacità in modo che possano virare

00:07:33.700 --> 00:07:36.220
server per indicare
forse chi possiede

00:07:36.220 --> 00:07:39.805
loro o se
fanno parte di una squadra.

00:07:39.805 --> 00:07:41.570
>> sì. Anche questo
significa che è solo

00:07:41.570 --> 00:07:43.670
come con altri Azure
risorse, giusto.

00:07:43.670 --> 00:07:46.100
Così, per esempio nel mio
ambiente tagga le risorse

00:07:46.100 --> 00:07:48.665
sulla base della produzione,
nell'ambiente di sviluppo,

00:07:48.665 --> 00:07:50.375
ambienti demo e così via;

00:07:50.375 --> 00:07:52.265
in modo che possano usare lo stesso tagging

00:07:52.265 --> 00:07:53.870
per i loro server fondamentalmente pre-prem?

00:07:53.870 --> 00:07:56.560
>> sì, esattamente. Ce l'hai fatta.

00:07:56.750 --> 00:07:59.340
Alla fine qui,

00:07:59.340 --> 00:08:01.670
viene generato questo script.

00:08:01.670 --> 00:08:03.650
Così ora si può prendere una copia di

00:08:03.650 --> 00:08:06.110
lo script ed eseguirlo
sul server di destinazione.

00:08:06.110 --> 00:08:09.485
Lasciate che vi mostri esattamente
il contenuto dello script.

00:08:09.485 --> 00:08:11.585
Quindi il primo è davvero tre passi.

00:08:11.585 --> 00:08:13.580
Una volta scaricato il pacchetto,

00:08:13.580 --> 00:08:17.270
ma se in realtà già
scaricato e messo in una condivisione di file,

00:08:17.270 --> 00:08:20.105
si può solo cambiare che per copiare
fuori da quella quota di potenza.

00:08:20.105 --> 00:08:23.195
Il secondo comando è quello di
installare tale pacchetto.

00:08:23.195 --> 00:08:25.100
L'ultimo è quello importante

00:08:25.100 --> 00:08:28.515
qui che siamo in realtà
durante l'onboarding.

00:08:28.515 --> 00:08:30.480
Questo strumento sarà effettivamente

00:08:30.480 --> 00:08:33.170
creare la risorsa ARM
e quindi collegare di nuovo a

00:08:33.170 --> 00:08:37.995
l'agente in modo che alla fine
del processo di onboarding,

00:08:37.995 --> 00:08:40.985
si vedrà effettivamente queste risorse

00:08:40.985 --> 00:08:44.300
presentando che fisico
server nel portale di Azure.

00:08:44.300 --> 00:08:45.485
>> Oh, che è impressionante.

00:08:45.485 --> 00:08:49.115
Quindi rendiamo super facile fondamentalmente
per i clienti di a bordo del

00:08:49.115 --> 00:08:51.050
server creando fondamentalmente

00:08:51.050 --> 00:08:53.315
loro lo script che
bisogno e, ovviamente,

00:08:53.315 --> 00:08:54.500
Penso che possano anche correre

00:08:54.500 --> 00:08:56.630
gli script contro
multipli di server se

00:08:56.630 --> 00:08:58.610
a bordo come non solo
uno o due server

00:08:58.610 --> 00:09:00.035
ma forse centinaia di server?

00:09:00.035 --> 00:09:01.355
>> Oh sì. assolutamente.

00:09:01.355 --> 00:09:04.340
>> Ok, è fantastico. Così
ora ho il mio server in

00:09:04.340 --> 00:09:05.870
il portale e posso vedere che e

00:09:05.870 --> 00:09:07.520
gestirlo utilizzando il
Azure Resource Manager,

00:09:07.520 --> 00:09:10.250
quali servizi possono
Io uso davvero ora?

00:09:10.250 --> 00:09:12.110
>> Sì, lasciate che ve lo mostri.

00:09:12.110 --> 00:09:15.740
Quindi, se si fa clic su uno dei
risorsa, come potete vedere qui,

00:09:15.740 --> 00:09:19.610
vogliamo davvero seguire il
Modello di macchina virtuale di Azure.Azure Virtual Machine model.

00:09:19.610 --> 00:09:25.145
Così si può vedere l'elenco di
capacità e man mano che andiamo avanti,

00:09:25.145 --> 00:09:28.655
ci accingiamo ad espandere su questi
gestione e capacità.

00:09:28.655 --> 00:09:33.320
Oggi stiamo abilitando
due servizi specifici.

00:09:33.320 --> 00:09:35.480
Uno che possiamo integrarlo con

00:09:35.480 --> 00:09:38.420
Log Analytics in modo che
si può effettivamente ottenere

00:09:38.420 --> 00:09:41.060
log aggiunti all'ID risorsa

00:09:41.060 --> 00:09:43.940
ed è possibile interrogare quelli
registri in un unico posto centrale.

00:09:43.940 --> 00:09:47.630
Lasciate che ve lo mostri. Se cliccherò
su "Logs" sarò in grado

00:09:47.630 --> 00:09:52.470
per ottenere tutti i registri
rilevanti per questo server.

00:09:54.320 --> 00:09:59.910
Senza questo, se il cliente cercando
per accedere a un registro per un server,

00:09:59.910 --> 00:10:01.790
hanno essenzialmente bisogno di andare
al server e figura

00:10:01.790 --> 00:10:03.980
a quale ID dell'area di lavoro si connette,

00:10:03.980 --> 00:10:05.230
e poi vieni al portale,

00:10:05.230 --> 00:10:07.040
trovare tale area di lavoro, e poi

00:10:07.040 --> 00:10:09.110
è possibile filtrare in base
sul nome del computer.

00:10:09.110 --> 00:10:10.865
Ora, con questa integrazione,

00:10:10.865 --> 00:10:13.130
si può semplicemente fare clic qui

00:10:13.130 --> 00:10:15.440
e poi ottenere tutti i registri
appartengono allo stesso server.

00:10:15.440 --> 00:10:16.700
>> Oh, è fantastico.

00:10:16.700 --> 00:10:18.470
Quindi questo mi aiuta anche come,

00:10:18.470 --> 00:10:19.760
Vedo un sacco di clienti che hanno

00:10:19.760 --> 00:10:21.560
una diversa parte organizzativa

00:10:21.560 --> 00:10:24.590
e alcuni di loro sono solo
davvero focalizzata sull'applicazione,

00:10:24.590 --> 00:10:28.040
così ora posso solo dare accesso
a questa squadra specifica per

00:10:28.040 --> 00:10:30.410
un insieme specifico di
server e possono

00:10:30.410 --> 00:10:33.360
basta accedere alle serrature per i serve?

00:10:33.360 --> 00:10:36.020
>> Sì, questo è in realtà un grande
beneficio che ha menzionato ci

00:10:36.020 --> 00:10:39.200
è a marzo il team di monitoraggio ha

00:10:39.200 --> 00:10:41.420
rilasciato questa nuova capacità
chiamata la risorsa

00:10:41.420 --> 00:10:45.620
ruolo RBAC centrico
l'accesso per i registri,

00:10:45.620 --> 00:10:49.685
e lo hanno reso disponibile per
Macchine virtuali di Azure ora con l'ambiente ibrido.

00:10:49.685 --> 00:10:52.705
Ora si può anche farlo
per il servizio pre-prem.

00:10:52.705 --> 00:10:55.715
>> Oh, che è impressionante. Così
hai anche menzionato le politiche.

00:10:55.715 --> 00:10:59.285
>> sì. Quindi i criteri di Azure sono

00:10:59.285 --> 00:11:01.700
il luogo in cui i clienti possono definire

00:11:01.700 --> 00:11:04.780
conformità e può anche
visualizzare lo stato di conformità.

00:11:04.780 --> 00:11:06.860
C'è questa particolare categoria di

00:11:06.860 --> 00:11:09.815
criteri denominati Guest
Criteri di configurazione.

00:11:09.815 --> 00:11:12.770
Si può pensare di Ospite
Criteri di configurazione quasi simili

00:11:12.770 --> 00:11:17.595
politiche di gruppo, ma per
server non aggiunti a un dominio.

00:11:17.595 --> 00:11:22.800
Quindi c'è una lunga lista di
Criteri di configurazione guest.

00:11:22.800 --> 00:11:26.495
Oggi abbiamo fatto 18 polizze integrate.

00:11:26.495 --> 00:11:30.335
Così si può effettivamente distribuire
destra fuori dalla scatola.

00:11:30.335 --> 00:11:35.149
Ma c'è anche, se si dispone di un
requisito che non integrato,

00:11:35.149 --> 00:11:37.295
si può effettivamente creare
tali criteri personalizzati

00:11:37.295 --> 00:11:40.055
e distribuirli in
un ambiente unico.

00:11:40.055 --> 00:11:42.440
Con l'ospite
Criteri di configurazione,

00:11:42.440 --> 00:11:46.025
in realtà funziona attraverso
ARM for the Azure VMs.

00:11:46.025 --> 00:11:48.695
Ora, con l'ibrido, possono anche essere

00:11:48.695 --> 00:11:52.275
monitoraggio e governo
server locali.

00:11:52.275 --> 00:11:54.090
Quindi, come potete vedere, ho distribuito

00:11:54.090 --> 00:11:56.315
alcuni degli Ospiti
Criteri di configurazione e

00:11:56.315 --> 00:12:00.755
in un'unica vista posso vedere tutti
questi stati non conformi.

00:12:00.755 --> 00:12:04.865
Se faccio il drill-down noto
i criteri password,

00:12:04.865 --> 00:12:07.610
Ho un mucchio di
servizi non conformi.

00:12:07.610 --> 00:12:09.620
Quindi lasciatemi venire qui, drill down,

00:12:09.620 --> 00:12:13.765
poi posso vedere tutti i server
che non sono conformi.

00:12:13.765 --> 00:12:17.120
Puoi vedere quale risorsa
gruppo a cui appartengono,

00:12:17.120 --> 00:12:19.475
in modo da poter avere un'idea
quello che stanno facendo.

00:12:19.475 --> 00:12:22.145
Ma anche qui è importante che,

00:12:22.145 --> 00:12:26.045
si tratta di macchine virtuali di Azure
e questi sono server locali.

00:12:26.045 --> 00:12:27.440
Quindi, in una vista, si ottiene

00:12:27.440 --> 00:12:30.470
un quadro completo di tutti i server
che non sono conformi.

00:12:30.470 --> 00:12:32.030
>> Wow, è fantastico.

00:12:32.030 --> 00:12:34.179
Così vedo tutti i miei server,

00:12:34.179 --> 00:12:35.730
non importa dove sono in esecuzione;

00:12:35.730 --> 00:12:37.770
se sono in esecuzione in Azure,
se sono in esecuzione in pre-prem,

00:12:37.770 --> 00:12:40.225
nei miei data center, in
le mie filiali,

00:12:40.225 --> 00:12:43.160
Posso vederli in un'unica vista

00:12:43.160 --> 00:12:45.680
e posso gestirli da Azure?

00:12:45.680 --> 00:12:48.830
>> Sì, questo è il nostro scopo
di avere Azure di essere

00:12:48.830 --> 00:12:50.930
l'unico posto centrale e vogliamo

00:12:50.930 --> 00:12:53.545
fornire l'esperienza coerente.

00:12:53.545 --> 00:12:55.230
>> Quindi questo è fantastico.

00:12:55.230 --> 00:12:56.685
Quindi, se sono un cliente oggi,

00:12:56.685 --> 00:12:57.930
come faccio a mettere le mani su questo?

00:12:57.930 --> 00:13:01.505
>> Sì, quindi siamo davvero
ottenere l'anteprima pubblica ora.

00:13:01.505 --> 00:13:03.680
Quindi, se si segue il
collegamento sullo schermo,

00:13:03.680 --> 00:13:05.990
sarete in grado di vedere
la nostra documentazione e

00:13:05.990 --> 00:13:08.935
il processo su come
iscriversi al servizio.

00:13:08.935 --> 00:13:10.275
>> Ok. È fantastico,

00:13:10.275 --> 00:13:12.120
e che dire del costo per questo?

00:13:12.120 --> 00:13:13.805
>> Oh sì. Questo è un ottimo punto.

00:13:13.805 --> 00:13:16.730
Ottenere un sacco di domande su
quanto pagherei

00:13:16.730 --> 00:13:20.135
e la buona notizia o
grande notizia è, è gratuito.

00:13:20.135 --> 00:13:22.520
Ciò significa che
in realtà non pagare

00:13:22.520 --> 00:13:25.070
per acsalire le macchine su Azure,

00:13:25.070 --> 00:13:27.410
e pagherai solo
per le soluzioni

00:13:27.410 --> 00:13:29.510
che si sta andando a
distribuire su tali server.

00:13:29.510 --> 00:13:31.070
>> Beh, questa è una notizia fantastica.

00:13:31.070 --> 00:13:32.630
Quindi grazie mille Chang '.

00:13:32.630 --> 00:13:34.370
Grazie per essere qui e mostrare

00:13:34.370 --> 00:13:36.245
noi questo ibrido
capacità di gestione.

00:13:36.245 --> 00:13:38.130
>> Sì, grazie