WEBVTT

00:00:00.000 --> 00:00:01.740
내 이름은 토마스 마우러입니다.

00:00:01.740 --> 00:00:04.770
나는 마이크로 소프트에서 클라우드 옹호자입니다
그리고 나는 여기에 앉아있어

00:00:04.770 --> 00:00:06.645
Azure 관리 팀의 Chang'

00:00:06.645 --> 00:00:08.635
하이브리드에 대해 이야기하려면
서버 관리.

00:00:08.635 --> 00:00:11.300
>> 그렇습니다. 안녕. 나는
Azure의 프로그램 관리자입니다.

00:00:11.300 --> 00:00:14.100
[> 안녕하세요. 그래서 나는 많은 이야기

00:00:14.100 --> 00:00:17.925
사용 중인 고객은
컴퓨팅 리소스용 클라우드.

00:00:17.925 --> 00:00:20.610
그러나 그들 중 대부분은
그들 중 많은 또한

00:00:20.610 --> 00:00:22.950
서버에서 실행중인
개인 데이터 센터,

00:00:22.950 --> 00:00:24.495
지사에서

00:00:24.495 --> 00:00:26.910
또는 다른 부품을
그들이 조직하는

00:00:26.910 --> 00:00:30.195
다른 클라우드 공급자를 사용하거나
다른 서비스 공급자.

00:00:30.195 --> 00:00:31.830
주요 과제 중 하나는

00:00:31.830 --> 00:00:34.490
이러한 모든 서버는
기본적으로 유지

00:00:34.490 --> 00:00:36.400
이 모든 것을 제어
서버가

00:00:36.400 --> 00:00:38.620
실행 중이면
안전하다는 것을

00:00:38.620 --> 00:00:42.085
그들은 패치 것을, 그
규정 준수가 있습니다.

00:00:42.085 --> 00:00:44.585
나는 Azure를 들었다
팀, 특히 여러분

00:00:44.585 --> 00:00:46.760
뭔가에 노력하고 있습니다
도움이 됩니다.

00:00:46.760 --> 00:00:49.940
>> 그렇습니다. 절대적 으로
나는 에 대해 이야기하는 것을 좋아합니다.

00:00:49.940 --> 00:00:53.240
그것그리고 나는 실제로 메아리치고 있었다
방금 언급한 내용입니다.

00:00:53.240 --> 00:00:55.835
그것은 참으로 큰 도전이다.

00:00:55.835 --> 00:00:59.990
그래서 많은 고객과 이야기를 나누었습니다.
뿐만 아니라 특히 그들은 필요

00:00:59.990 --> 00:01:03.890
이러한 매우 같은 관리
하이브리드 환경,

00:01:03.890 --> 00:01:05.345
그래서 우리는 여기저기 서 있습니다

00:01:05.345 --> 00:01:07.490
응용 프로그램 팀과 함께
그냥 나가려고,

00:01:07.490 --> 00:01:08.930
필요한 모든 리소스를 얻을 수 있습니다.

00:01:08.930 --> 00:01:10.010
어떤 클라우드,

00:01:10.010 --> 00:01:12.845
그들은 단지 에 가서
배포할 수 있습니다.

00:01:12.845 --> 00:01:15.560
반면에 IT는
이해하려고 노력,

00:01:15.560 --> 00:01:17.540
오, 내 고쉬, 모든 것이 어디 있니?

00:01:17.540 --> 00:01:19.070
모든 데이터는 어디에 있습니까?

00:01:19.070 --> 00:01:21.650
어떤 일이 발생하면 어떻게 됩니까?
뭔가 위반있어?

00:01:21.650 --> 00:01:24.545
특히 지금 당신은 볼 수
여기저기 뉴스.

00:01:24.545 --> 00:01:29.210
그래서 이것은 정말 뭔가
Azure는 항상 생각하고 있습니다.

00:01:29.210 --> 00:01:31.760
에 대한 특히 서비스

00:01:31.760 --> 00:01:34.970
오늘 이미
온프레미 서비스 관리.

00:01:34.970 --> 00:01:36.470
하지만 지금은이 서비스와 함께,

00:01:36.470 --> 00:01:39.620
우리는 정말 그것을 복용
다음 단계로 이동합니다.

00:01:39.620 --> 00:01:43.160
이러한 서버 통합
Azure에 더 많이 들어갑니다.

00:01:43.160 --> 00:01:44.975
>> 좋아. 그것은 환상적으로 들립니다.

00:01:44.975 --> 00:01:46.640
그래서 당신은 통합에 대해 이야기 할 때

00:01:46.640 --> 00:01:49.115
Azure로 의 한 서비스,
그게 무슨 뜻인가요?

00:01:49.115 --> 00:01:51.260
>> 그렇습니다. 나는 보여주기 를 좋아한다.
당신은 그것의 사진.

00:01:51.260 --> 00:01:52.070
>> 완벽합니다. 감사합니다.

00:01:52.070 --> 00:01:56.630
>> 서비스는 다음과 같습니다.
이러한 환경을 관리합니다.

00:01:56.630 --> 00:01:59.070
그래서 이러한 서비스는 실제로,

00:01:59.070 --> 00:02:01.560
오늘 모든 관리 온 프레미 서비스.

00:02:01.560 --> 00:02:03.470
그건 그렇고, 나는 전화
온-프레미 서버

00:02:03.470 --> 00:02:05.480
하지만 실제로는 그렇지 않습니다.
그들이 어디에 있는지 중요합니다.

00:02:05.480 --> 00:02:07.400
데이터 센터의 온프레미가 될 수 있습니다.

00:02:07.400 --> 00:02:10.580
개인 데이터 센터 또는
클라우드의 다른 호스트.

00:02:10.580 --> 00:02:11.975
하지만 당신이 볼 수 있듯이,

00:02:11.975 --> 00:02:15.170
이러한 모든 서버는
를 통한 Azure 가상 시스템

00:02:15.170 --> 00:02:18.515
Azure라는 것
리소스 관리자, ARM에 대한 짧은,

00:02:18.515 --> 00:02:21.305
그리고 온프레미 서버의 경우,

00:02:21.305 --> 00:02:24.485
그들은 정말 그림이 필요
코드를 얻을 수있는 방법을 꺼내십시오.

00:02:24.485 --> 00:02:28.220
온프레미에 배포
서버를 개별적으로 관리해야 합니다.

00:02:28.220 --> 00:02:29.840
그래서 당신이 볼 수 있듯이,

00:02:29.840 --> 00:02:32.180
사이에 약간의 차이가 있습니다.

00:02:32.180 --> 00:02:35.540
튜브 패널과 이

00:02:35.540 --> 00:02:39.320
내가 기본적으로 무엇을 의미하는지 정말이다
ARM에 통합됩니다.

00:02:39.320 --> 00:02:43.315
이제 그들은
ARM 리소스를 Azure로 변환합니다.

00:02:43.315 --> 00:02:45.295
이점은 엄중할 것입니다.

00:02:45.295 --> 00:02:48.220
많은 것을 볼 수 있듯이
투자는 ARM에 들어갔다;

00:02:48.220 --> 00:02:50.710
정체성처럼, 같은
RBAC, 정책처럼.

00:02:50.710 --> 00:02:53.170
가장 중요한 것은
고객들은

00:02:53.170 --> 00:02:57.460
규정 준수 및 정기적인 규정 준수
태그와 같은 관리,

00:02:57.460 --> 00:02:59.800
내 서버가 무엇인지 보여
생산에 모두,

00:02:59.800 --> 00:03:03.820
그런 종류의 간단한 것들
ARM을 통해 모두 할 수 있습니다.

00:03:03.820 --> 00:03:07.930
그래서 지금은 한 번 프로젝트가
이러한 서버를 ARM으로,

00:03:07.930 --> 00:03:09.520
나는 이 모든 혜택을 얻습니다.

00:03:09.520 --> 00:03:12.160
또한, 모든
이제 서비스를 받을 수 있습니다.

00:03:12.160 --> 00:03:16.725
Azure에 배포할 수 있습니다.
같은 방식으로 온 - 프레임.

00:03:16.725 --> 00:03:18.000
여기에서 볼 수 있듯이,

00:03:18.000 --> 00:03:22.805
나는이 매우 중요한 라벨
게스트 에이전트라는 구성 요소입니다.

00:03:22.805 --> 00:03:25.250
이 것의 목적은
에이전트는 관리해야 합니다.

00:03:25.250 --> 00:03:28.430
이러한 수명 주기는
확장 및 우리는 다음과

00:03:28.430 --> 00:03:30.635
같은 모델이 지금

00:03:30.635 --> 00:03:34.630
이러한 모든 확장을 적용할 수 있습니다.
온-프레미 서비스에도 영향을 미칠 수 있습니다.

00:03:34.630 --> 00:03:38.700
>> 그래서 대단하지 요. 그래서 우리의 서버
Azure 리소스로 표시됩니다.

00:03:38.700 --> 00:03:41.480
그들은 포털에 표시하고 또한
Azure 리소스 관리자에서

00:03:41.480 --> 00:03:44.330
나는 기본적으로 치료 할 수 있습니다
기계처럼,

00:03:44.330 --> 00:03:47.195
내가 Azure와 함께 하는 데 사용 처럼
가상 머신, 맞죠?

00:03:47.195 --> 00:03:49.759
>> 예. 에서
관리 관점,

00:03:49.759 --> 00:03:51.500
이것이 우리의 핵심 목표입니다.

00:03:51.500 --> 00:03:54.170
우리는 이 모든 것을 원했습니다.
관리할 솔루션

00:03:54.170 --> 00:03:57.470
동일한 방식으로 서버
Azure뿐만 아니라

00:03:57.470 --> 00:04:03.805
온 프렘에 대한 또한 그들은
동일한 ARM 혜택을 받을 수 있습니다.

00:04:03.805 --> 00:04:05.360
>> 좋아, 정말 대단하군요.

00:04:05.360 --> 00:04:07.850
그래서 지금 그것을 사용하고 싶습니다.

00:04:07.850 --> 00:04:11.215
그래서 당신은 우리가 어떻게 나에게 보여줄 수 있습니다
Azure에 이 서비스를 온보드로 이동합니까?

00:04:11.215 --> 00:04:13.460
>> 절대적으로, 하자
나는 당신에게 데모를 보여줍니다.

00:04:13.460 --> 00:04:15.560
이 페이지는 우리가 보여주기 위해 만든 페이지입니다

00:04:15.560 --> 00:04:19.960
모든 온프레미 서버는
Azure에 온보드되었습니다.

00:04:19.960 --> 00:04:23.890
본질적으로 온보드,
고객이 실행해야 합니다.

00:04:23.890 --> 00:04:27.790
서버에서 스크립트를
스크립트를 작성하는 데 도움이 됩니다.

00:04:27.790 --> 00:04:32.840
우리는 실제로 흐름을 구축
해당 스크립트를 생성할 Azure입니다.

00:04:33.260 --> 00:04:36.235
그래서 이것은 그들이 할 수있는 옵션입니다

00:04:36.235 --> 00:04:39.100
클릭하여 스크립트를 생성합니다.
그러나 동시에,

00:04:39.100 --> 00:04:42.520
그것은 또한 도전이다 인식
고객이 기내에 탑승할 수 있도록

00:04:42.520 --> 00:04:44.080
연결해야 하는 경우 배율

00:04:44.080 --> 00:04:46.705
모든 단일 서버는 개별적으로
을 사용하여 이러한 스크립트를 실행합니다.

00:04:46.705 --> 00:04:49.240
그래서 우리는 또한 노력하고 있습니다
무엇을 이해하기 위해

00:04:49.240 --> 00:04:53.140
몇 가지 일반적인 온 프레미 서버
관리 응용 프로그램 그래서 우리는 할 수

00:04:53.140 --> 00:04:57.505
통합하여 고객이
이러한 기계를 대규모로 탑재할 수 있습니다.

00:04:57.505 --> 00:05:00.295
예를 들어,
서버가 이미 있습니다.

00:05:00.295 --> 00:05:03.100
Azure 업데이트 서비스에서 관리하며,

00:05:03.100 --> 00:05:05.120
우리는 실제로 스크립트를 작성합니다.

00:05:05.120 --> 00:05:07.640
또는 실제로 실행책을
온보드에 배포

00:05:07.640 --> 00:05:10.505
Azure에 해당 컴퓨터

00:05:10.505 --> 00:05:13.055
실제로 고객 없이
모든 기계를 만지고.

00:05:13.055 --> 00:05:15.770
그러나 미래에, 우리는 또한
예를 들어,

00:05:15.770 --> 00:05:19.129
시스템 센터 구성 관리자
또한 통합하고 있습니다.

00:05:19.129 --> 00:05:20.870
온보딩 경험과

00:05:20.870 --> 00:05:22.580
윈도우 관리 센터뿐만 아니라.

00:05:22.580 --> 00:05:25.850
그래서 우리는 계속
고객이 할 수 있는 방법에 대한 확장

00:05:25.850 --> 00:05:29.240
온보드에서 Azure로 이동
최소한의 노력 방법.

00:05:29.240 --> 00:05:32.630
그러나이 경우, 내가 보여 보자
스크립트를 생성하는 방법을 설명합니다.

00:05:32.630 --> 00:05:35.510
그래서 당신은 이것들을 볼 수 있듯이
은 Azure 리소스입니다.

00:05:35.510 --> 00:05:37.220
그래서 그들은 동일한 계층 구조를 따릅니다.

00:05:37.220 --> 00:05:39.140
구독에서와 같이
및 리소스 그룹.

00:05:39.140 --> 00:05:40.385
그래서 지금 당신은 선택할 수 있습니다

00:05:40.385 --> 00:05:44.870
어떤 구독 및 리소스
그들이 가고 싶었던 그룹

00:05:44.870 --> 00:05:46.790
이 지역은

00:05:46.790 --> 00:05:48.950
실행 중인 Azure 지역

00:05:48.950 --> 00:05:51.980
이러한 서버관리
이러한 온프레미 리소스.

00:05:51.980 --> 00:05:56.930
따라서 규정 준수를 통해 확인할 수 있습니다.
또는 규제 포인트 관점,

00:05:56.930 --> 00:05:59.635
우리는 메타데이터가 어디에 있는지 알고 있습니다.
Azure에 저장됩니다.

00:05:59.635 --> 00:06:03.620
물리적 위치는 특별히 새로운
온-프레미 서버에 대한 서버용입니다.

00:06:03.620 --> 00:06:06.245
이를 통해 고객은
서버에 태그를 붙이려면

00:06:06.245 --> 00:06:10.655
또는 구체적으로
에 있는 데이터 센터입니다.

00:06:10.655 --> 00:06:13.940
이것은 정말로 에 관한 것입니다.
관리의 용이성.

00:06:13.940 --> 00:06:15.440
>> 좋아, 정말 멋지군요.

00:06:15.440 --> 00:06:18.650
따라서 고객은 단지 추가 할 수 없습니다.
데이터 센터 위에 이름을 지정합니다.

00:06:18.650 --> 00:06:20.330
그래서 그들은 심지어 같은 수 있습니다., 예를 들어,

00:06:20.330 --> 00:06:22.460
또한 위치의 방을 추가하거나

00:06:22.460 --> 00:06:25.520
심지어 직접 이름 또는 직접
서버 번호?

00:06:25.520 --> 00:06:26.570
물론 그렇습니다.

00:06:26.570 --> 00:06:28.670
그래서 이것은 정말 고객을위한 것입니다

00:06:28.670 --> 00:06:31.100
쉽게 식별할 수 있습니다.
리소스가 있는 위치입니다.

00:06:31.100 --> 00:06:32.750
해당 서버에 문제가 발생하면

00:06:32.750 --> 00:06:34.810
필요한 경우 갈 수 있습니다.
물리적으로 액세스하려면

00:06:34.810 --> 00:06:37.160
그들은 정확히 알고
필요한 곳에 있어야 합니다.

00:06:37.160 --> 00:06:41.825
여기에서 우리는 또한 고객이
운영 체제를 선택합니다.

00:06:41.825 --> 00:06:45.200
나는 정말로 구체적으로 하지 않았다.
그것을 밖으로 철자하지만, 언제나처럼,

00:06:45.200 --> 00:06:48.395
Azure에서 우리는 포용하려고 합니다.
윈도우뿐만 아니라 리눅스.

00:06:48.395 --> 00:06:50.570
우리가 구축하는 여기에 대해 동일

00:06:50.570 --> 00:06:52.820
에이전트를 위한 두 개의 패키지가

00:06:52.820 --> 00:06:56.460
온보드 윈도우
서버 또는 리눅스 서버.

00:06:57.380 --> 00:07:01.200
많은 고객 이해
특히 온 프렘에 대한,

00:07:01.200 --> 00:07:03.520
그들은 원하지 않는다.
서버를

00:07:03.520 --> 00:07:06.805
인터넷을 직접 적으로
프록시 서버 뒤에 놓습니다.

00:07:06.805 --> 00:07:12.050
그래서 여기에이 경우 우리의 에이전트
Azure에 연결해야 합니다.

00:07:14.280 --> 00:07:18.400
이러한 서버가
Azure에 직접 연결합니다.

00:07:18.400 --> 00:07:21.610
그들은 구성 할 수 있습니다
프록시 서버는 여기 그리고 나서

00:07:21.610 --> 00:07:26.000
상담원이 의사소통을 할 수 있습니다.
프록시 서버를 통해

00:07:26.880 --> 00:07:33.700
이것은 단지 Azure 리소스일 뿐입니다.
그들은 압정 할 수 있도록 기능

00:07:33.700 --> 00:07:36.220
서버를 표시합니다.
어쩌면 누가 소유

00:07:36.220 --> 00:07:39.805
또는 그들이
팀의 일부입니다.

00:07:39.805 --> 00:07:41.570
>> 그렇습니다. 이것은 또한
그것은 단지 것을 의미

00:07:41.570 --> 00:07:43.670
다른 Azure와 같이
리소스, 오른쪽.

00:07:43.670 --> 00:07:46.100
그래서 예를 들어 내
환경 I 태그 리소스

00:07:46.100 --> 00:07:48.665
생산에 따라,
개발 환경,

00:07:48.665 --> 00:07:50.375
데모 환경 등;

00:07:50.375 --> 00:07:52.265
동일한 태그를 사용할 수 있습니다.

00:07:52.265 --> 00:07:53.870
그들의 기본적으로 온 - 프레미 서버에 대한?

00:07:53.870 --> 00:07:56.560
정확히 그렇습니다. 당신은 그것을 얻었다.

00:07:56.750 --> 00:07:59.340
결국,

00:07:59.340 --> 00:08:01.670
이 스크립트를 생성합니다.

00:08:01.670 --> 00:08:03.650
이제 사본을 가져갈 수 있습니다.

00:08:03.650 --> 00:08:06.110
스크립트를 실행하고 실행합니다.
대상 서버에서 볼 수 있습니다.

00:08:06.110 --> 00:08:09.485
내가 정확히 보여 드리겠습니다
스크립트 콘텐츠입니다.

00:08:09.485 --> 00:08:11.585
그래서 첫 번째는 정말 세 단계입니다.

00:08:11.585 --> 00:08:13.580
패키지를 다운로드한 후

00:08:13.580 --> 00:08:17.270
하지만 당신은 실제로 이미
다운로드하여 파일 공유에 넣어,

00:08:17.270 --> 00:08:20.105
복사할 수 있도록 변경할 수 있습니다.
그 전력 공유에서 벗어났습니다.

00:08:20.105 --> 00:08:23.195
두 번째 명령은
해당 패키지를 설치합니다.

00:08:23.195 --> 00:08:25.100
마지막 하나는 중요한 것입니다

00:08:25.100 --> 00:08:28.515
우리가 실제로 있는 여기
탑승 하는 동안.

00:08:28.515 --> 00:08:30.480
이 도구는 실제로

00:08:30.480 --> 00:08:33.170
ARM 리소스 만들기
다음으로 다시 연결합니다.

00:08:33.170 --> 00:08:37.995
에이전트가 끝날 때
온보딩 프로세스의

00:08:37.995 --> 00:08:40.985
이러한 리소스가 실제로 표시됩니다.

00:08:40.985 --> 00:08:44.300
물리적 인 제시
Azure 포털의 서버입니다.

00:08:44.300 --> 00:08:45.485
오, 정말 대단하군요.

00:08:45.485 --> 00:08:49.115
그래서 우리는 기본적으로 슈퍼 쉽게
고객이 기내에 탑승할 수 있도록

00:08:49.115 --> 00:08:51.050
기본적으로 서버를 생성하여

00:08:51.050 --> 00:08:53.315
그들은 스크립트를
필요하고 명백하게,

00:08:53.315 --> 00:08:54.500
나는 그들이 또한 실행할 수 있다고 생각

00:08:54.500 --> 00:08:56.630
에 대한 스크립트
서버의 배수가

00:08:56.630 --> 00:08:58.610
그냥 같은 온보드
하나 또는 두 개의 서버

00:08:58.610 --> 00:09:00.035
하지만 어쩌면 서버의 수백?

00:09:00.035 --> 00:09:01.355
>> 오, 그래. 절대적 으로.

00:09:01.355 --> 00:09:04.340
>> 좋아, 좋아. 그래서
이제 내 서버가

00:09:04.340 --> 00:09:05.870
포털과 나는 그것을 볼 수 있습니다

00:09:05.870 --> 00:09:07.520
을 사용하여 관리합니다.
Azure 리소스 관리자,

00:09:07.520 --> 00:09:10.250
어떤 서비스가 할 수 있는가
나는 실제로 지금 사용?

00:09:10.250 --> 00:09:12.110
네, 보여드리겠습니다.

00:09:12.110 --> 00:09:15.740
그래서 만약 당신이 하나를 클릭 합니다.
여기에서 볼 수 있듯이 리소스는

00:09:15.740 --> 00:09:19.610
우리는 정말로
Azure 가상 컴퓨터 모델입니다.

00:09:19.610 --> 00:09:25.145
그래서 당신은 의 목록을 볼 수 있습니다
역량을 갖추고 우리가 앞으로 나아갈 때,

00:09:25.145 --> 00:09:28.655
우리는 이것들을 확장할 것입니다.
관리 및 기능을 제공합니다.

00:09:28.655 --> 00:09:33.320
오늘 우리는
두 가지 특정 서비스.

00:09:33.320 --> 00:09:35.480
우리는 그것을 통합 할 수 있습니다 하나

00:09:35.480 --> 00:09:38.420
로그 분석
당신은 실제로 얻을 수 있습니다

00:09:38.420 --> 00:09:41.060
리소스 ID에 추가된 로그

00:09:41.060 --> 00:09:43.940
그리고 당신은 그 쿼리 할 수 있습니다
한 중앙 장소에 로그.

00:09:43.940 --> 00:09:47.630
그래서 내가 당신을 보여 드리겠습니다. 클릭하면
"로그"에 나는 할 수있을 것입니다

00:09:47.630 --> 00:09:52.470
모든 로그를 얻으려면
이 서버와 관련이 있습니다.

00:09:54.320 --> 00:09:59.910
이것 없이, 고객이 시도하는 경우
서버의 로그에 액세스하려면

00:09:59.910 --> 00:10:01.790
그들은 본질적으로 갈 필요가
서버와 그림으로

00:10:01.790 --> 00:10:03.980
어떤 작업 영역 ID에 연결되는지,

00:10:03.980 --> 00:10:05.230
그리고 포털에 와서,

00:10:05.230 --> 00:10:07.040
해당 작업 영역을 찾은 다음

00:10:07.040 --> 00:10:09.110
당신은 기반 필터링 할 수 있습니다
컴퓨터 이름에 있습니다.

00:10:09.110 --> 00:10:10.865
이제 이 통합을 통해

00:10:10.865 --> 00:10:13.130
당신은 단순히 여기를 클릭 할 수 있습니다

00:10:13.130 --> 00:10:15.440
그런 다음 모든 로그를 가져옵니다.
동일한 서버에 속합니다.

00:10:15.440 --> 00:10:16.700
오, 정말 환상적입니다.

00:10:16.700 --> 00:10:18.470
그래서 이것은 또한 나를 좋아합니다.

00:10:18.470 --> 00:10:19.760
많은 고객이

00:10:19.760 --> 00:10:21.560
다른 조직 부분

00:10:21.560 --> 00:10:24.590
그리고 그들 중 일부는 단지
정말 응용 프로그램 초점을 맞추고,

00:10:24.590 --> 00:10:28.040
그래서 난 지금 그냥 액세스를 제공 할 수 있습니다
특정 팀에

00:10:28.040 --> 00:10:30.410
특정 세트는
서버와 함께 할 수 있습니다.

00:10:30.410 --> 00:10:33.360
그냥 서브에 대한 자물쇠에 액세스?

00:10:33.360 --> 00:10:36.020
>> 그래, 그건 실제로 좋은
거기에 언급 한 혜택

00:10:36.020 --> 00:10:39.200
3월에 모니터링 팀이

00:10:39.200 --> 00:10:41.420
이 새로운 기능을 출시했습니다.
리소스라고 합니다.

00:10:41.420 --> 00:10:45.620
중심 RBAC 역할
로그에 대한 액세스,

00:10:45.620 --> 00:10:49.685
그리고 그들은 그것을 사용할 수 있게 했습니다.
이제 하이브리드와 함께 Azure VM을

00:10:49.685 --> 00:10:52.705
지금 당신은 또한 그것을 얻을 수 있습니다
온프레미 서비스를 위한 서비스.

00:10:52.705 --> 00:10:55.715
오, 정말 대단하군요. 그래서
또한 정책을 언급했습니다.

00:10:55.715 --> 00:10:59.285
>> 그렇습니다. 따라서 Azure 정책은

00:10:59.285 --> 00:11:01.700
고객이 정의할 수 있는 장소

00:11:01.700 --> 00:11:04.780
규정 준수를 통해
규정 준수 상태를 볼 수 있습니다.

00:11:04.780 --> 00:11:06.860
이 특정 범주는

00:11:06.860 --> 00:11:09.815
게스트라는 정책
구성 정책.

00:11:09.815 --> 00:11:12.770
게스트를 생각할 수 있습니다.
거의 같은 구성 정책

00:11:12.770 --> 00:11:17.595
그룹 정책에 대한
도메인이 아닌 서버가 가입되었습니다.

00:11:17.595 --> 00:11:22.800
그래서 의 긴 목록이있다
게스트 구성 정책.

00:11:22.800 --> 00:11:26.495
우리는 오늘 18 개의 기본 제공 정책을 만들었습니다.

00:11:26.495 --> 00:11:30.335
따라서 실제로 배포할 수 있습니다.
상자에서 바로 꺼낼 수 있습니다.

00:11:30.335 --> 00:11:35.149
그러나 또한, 만약 당신이
기본 제공이 아닌 요구 사항,

00:11:35.149 --> 00:11:37.295
당신은 실제로 만들 수 있습니다
이러한 사용자 지정 정책

00:11:37.295 --> 00:11:40.055
에 배포
독특한 환경을 조성합니다.

00:11:40.055 --> 00:11:42.440
게스트와 함께
구성 정책,

00:11:42.440 --> 00:11:46.025
그것은 실제로 통해 작동
Azure VM에 대한 ARM입니다.

00:11:46.025 --> 00:11:48.695
이제 하이브리드를 사용하면

00:11:48.695 --> 00:11:52.275
모니터링 및 관리
온-프레미 서버.

00:11:52.275 --> 00:11:54.090
그래서 당신이 볼 수 있듯이, 나는 배포

00:11:54.090 --> 00:11:56.315
일부 게스트
구성 정책 및

00:11:56.315 --> 00:12:00.755
하나의 보기에서 나는 모든 것을 볼 수 있습니다
이러한 비준수 상태입니다.

00:12:00.755 --> 00:12:04.865
드릴다운하면
암호 정책,

00:12:04.865 --> 00:12:07.610
나는 의 무리가
비준수 서비스.

00:12:07.610 --> 00:12:09.620
그래서 내가 여기 와서 드릴다운하자,

00:12:09.620 --> 00:12:13.765
그런 다음 모든 서버를 볼 수 있습니다.
규정을 준수하지 않습니다.

00:12:13.765 --> 00:12:17.120
어떤 리소스를 볼 수 있습니다.
그들이 속한 그룹,

00:12:17.120 --> 00:12:19.475
그래서 당신은 아이디어를 얻을 수 있습니다
그들이 하고 있는 일.

00:12:19.475 --> 00:12:22.145
그러나 또한 여기에서 중요한 것은,

00:12:22.145 --> 00:12:26.045
이들은 Azure 가상 머신입니다.
그리고 이들은 온 프레임 서버입니다.

00:12:26.045 --> 00:12:27.440
따라서 하나의 뷰에서

00:12:27.440 --> 00:12:30.470
모든 서버의 전체 그림
준수하지 않습니다.

00:12:30.470 --> 00:12:32.030
와우, 정말 환상적입니다.

00:12:32.030 --> 00:12:34.179
그래서 내 모든 서버를 참조하십시오,

00:12:34.179 --> 00:12:35.730
실행 중인 위치는 중요하지 않습니다.

00:12:35.730 --> 00:12:37.770
Azure에서 실행 중인 경우
만약 그들이 온프레미로 달리고 있다면,

00:12:37.770 --> 00:12:40.225
내 데이터 센터에서
내 지점,

00:12:40.225 --> 00:12:43.160
하나의 뷰를 볼 수 있습니다.

00:12:43.160 --> 00:12:45.680
Azure에서 관리할 수 있습니까?

00:12:45.680 --> 00:12:48.830
그것은 우리의 목적입니다.
Azure를 갖는 것은

00:12:48.830 --> 00:12:50.930
하나의 중앙 장소와 우리는

00:12:50.930 --> 00:12:53.545
일관된 경험을 제공합니다.

00:12:53.545 --> 00:12:55.230
>> 그래서 환상적입니다.

00:12:55.230 --> 00:12:56.685
그래서 만약 내가 오늘 고객,

00:12:56.685 --> 00:12:57.930
어떻게 이것에 내 손을 얻을 수 있습니까?

00:12:57.930 --> 00:13:01.505
>> 예, 그래서 우리는 정말
이제 공개 미리 보기를 얻을 수 있습니다.

00:13:01.505 --> 00:13:03.680
그래서 만약 당신이 따르는 경우
화면에 링크,

00:13:03.680 --> 00:13:05.990
당신은 볼 수 있습니다
우리의 문서와

00:13:05.990 --> 00:13:08.935
프로세스에 대한 프로세스를
서비스에 등록할 수 있습니다.

00:13:08.935 --> 00:13:10.275
>> 좋아. 환상적이에요

00:13:10.275 --> 00:13:12.120
그리고 이것에 대한 비용은 어떻습니까?

00:13:12.120 --> 00:13:13.805
>> 오, 그래. 그것은 좋은 점입니다.

00:13:13.805 --> 00:13:16.730
에 대한 질문을 많이 받기
얼마를 지불할 것인가?

00:13:16.730 --> 00:13:20.135
그것 및 좋은 소식 또는
좋은 소식은 무료입니다.

00:13:20.135 --> 00:13:22.520
즉,
실제로 지불하지 마십시오.

00:13:22.520 --> 00:13:25.070
컴퓨터를 Azure에 온보로

00:13:25.070 --> 00:13:27.410
그리고 당신은 단지 지불합니다
솔루션용

00:13:27.410 --> 00:13:29.510
서버에 배포할 수 있습니다.

00:13:29.510 --> 00:13:31.070
>> 그건 환상적인 소식입니다.

00:13:31.070 --> 00:13:32.630
그래서 대단히 감사합니다 장'.

00:13:32.630 --> 00:13:34.370
여기에 와서 보여 주셔서 감사합니다

00:13:34.370 --> 00:13:36.245
우리에게이 하이브리드
관리 기능을 제공합니다.

00:13:36.245 --> 00:13:38.130
>> 예, 감사합니다