프리지아 랩

Azure AD와 AD 동기화 후 고아가된 계정 삭제 방법


[작업 환경]
Microsoft Windows 10 Pro 빌드 16299


Azure AD Connect를 사용해 AD 온프레미스 AD나 AD가 구현된 Azure VM의 AD 계정을 Azure AD와 동기화한 경우, 해당 Azure AD 테넌트에서 사용자 계정 목록을 보면, [SOURCE] 부분의 값은 Windows Server AD와 Azure Active Directory로 나뉜다. 



전자는 동기화한 원본이 다른 AD DS에서 있고, 후자는 Azure AD 테넌트에서 직접 만든 계정이거나 해당 구독의 전역 관리자 계정인 경우다. 

당연히 구독의 전역 관리자 계정은 삭제할 수 없으며 역할도 변경할 수 없다.



그러나 추가 Azure AD 테넌트에서 만든 계정은 역할 변경도 가능하고 삭제도 할 수 있다. 



Azure AD와 AD 동기화 후 기존 AD DS가 제거된 경우, Azure AD의 계정은 Azure 포털에서 변경도 제거도 하지 못한다. 

이런 경우를 "고아 계정"이라고 한다. 


추가한 Azure AD 테넌트를 제거하려는 경우 이런 고아 계정을 포함해 해당 테넌트에서 만든 계정을 모두 삭제한 상태여야 한다. 

고아 계정의 삭제는 Azure AD PowerShell 모듈을 통해 해결할 수 있다.


현재 Azure Active Directory 관리는 MSOnline PowerShell 모듈(Azure AD PowerShell V1)과 Azure Active Directory PowerShell for Graph(Azure AD PowerShell V2)에서 가능하지만, V1은 사용중지가 예고되어 있으므로, V2 사용을 권장한다. 

V2는 미리보기 버전과 GA 버전이 있으며, 미리보기 버전은 운영환경에서 사용을 권장하지 않는다.


MSOnline PowerShell 모듈

MSOnline PowerShell 모듈은 Windows PowerShell 명령을 위한 Azure Active Directory Module이다. 

이들 명령으로 사용자 관리와 도메인 관리, SSO 구성 등의 관리 작업을 한다.

이 모듈을 설치하는 가장 쉬운 방법은 Install-Module 명령으로 PowerShell 갤러리에서 모듈을 설치하는 것이다.



모듈을 설치하고 포함된 명령을 확인해보면 명령에 공통적으로 "Msol" 키워드가 포함된 것을 알 수 있다.



제일 먼저 할 일은 온라인 서비스에 연결하는 일이다. 

이때 해당 AAD 테넌트의 관리자 자격증명으로 인증해야 한다. 

예를 들어, AAD 테넌트의 이름이 steelfleaadatum이고 관리자 계정이 SyncAdmin인 경우 UPN을 사용한 로그인 화면은 다음과 같다.



인증이 성공하면, Get-MsolUser 명령으로 해당 AAD 테넌트의 계정을 확인할 수 있다.



Azure Active Directory PowerShell for Graph

현재 권장하는 Azure AD PowerShell V2 명령을 사용하려면 물론 해당 모듈을 설치해야 한다.
앞서와 동일한 Install-Module 명령으로 PowerShell 갤러리에서 설치할 수 있는데, 모듈 이름은 AzureAD다. 



모듈 설치 후 관련 명령을 확인해 봤다. 명령의 이름에 공통적으로 "AzureAd"라는 키워드가 포함된 것을 알 수 있다.




제일 먼저 할 일은 Connect-AzureAD 명령으로 Azure AD 테넌트에 연결하는 일이다. 

이때 해당 AAD 테넌트의 관리자 자격증명으로 인증해야 한다. 

예를 들어, AAD 테넌트의 이름이 steelfleaadatum이고 관리자 계정이 SyncAdmin인 경우 UPN을 사용한 로그인 화면은 다음과 같다.



Azure AD 테넌트 연결을 끊을 때는 Disconnect-AzureAD 명령을 사용한다.

인증이 성공하면, Get-AzureADUser 명령으로 해당 AAD 테넌트의 계정을 확인할 수 있다.



이제 Remove-AzureADUser 명령으로 고아 계정을 삭제한다. 

앞서 상위 5개의 일반 사용자 계정을 삭제하고 온프레미스 디렉터리 동기화 서비스 계정을 추가로 삭제한다.



이제, Azure 포털에서 해당 AAD 테넌트의 관리자 계정을 삭제한다.



마지막으로, 구독 전역 관리자 계정만 남긴 상태에서 AAD 테넌트를 삭제를 시도하면, 삭제 가능한지 여부를 확인한다. 

다음 화면은 삭제할 수 있는 모든 조건이 통과 되었음을 나타낸다.



Comment +0

 Azure에서 PowerShell을 사용한 가상 네트워크와 서브넷을 만들때 범할 수 있는 실수.


Azure에서 PowerShell을 사용해 가상네트워크와 서브넷을 만드는 방법은 두 가지 입니다.

1. New-AzureRmVirtualNetworkSubnetConfig를 먼저 실행한 후, New-AzureRmVirtualNetwork을 실행하는 방법.

2. New-AzureRmVirtualNetwork으로 가상 네트워크를 먼저 만든 후, Add-AzureRmVirtualNetworkSubnetConfig를 실행하는 방법.

물론, 최종적으로 Set-AzureRmVirtualNetwork으로 설정을 업데이트 해야 합니다.

두 가지 방법 모두 가상네트워크를 만들고 해당 네트워크에 서브넷을 만들지만, 각 방법으로 만든 서브넷의 정보를 보면 다음 차이가 있습니다.

1번의 방법으로 한 경우, 



2번의 방법으로 한 경우,


두 가지 결과의 차이점이 보이나요?

2번 방법은 Id와 Etag 값이 없습니다.
이런 경우 네트워크 카드 리소스를 만들때 지정해야 하는 서브넷 ID를 사용하지 못하니 문제가 됩니다.

여기서 중요한 PowerShell 사용의 실수가 나옵니다.

2번의 경우 먼저, 다음과 같이 가상 네트워크를 만듭니다.

$vnet3 = New-AzureRmVirtualNetwork -ResourceGroupName $rg2.ResourceGroupName -Name 'AzureBCKor02-VNet1' -AddressPrefix '10.12.0.0/16' -Location $locName

그리고 여기에 서브넷을 다음과 같이 추가하겠죠.
$subnet4=Add-AzureRmVirtualNetworkSubnetConfig -Name 'VNet3SubNet1' -AddressPrefix '10.12.0.0/24' -VirtualNetwork $vnet3

그 다음, 최종적으로 설정을 업데이트 합니다.

Set-AzureRmVirtualNetwork -VirtualNetwork $vnet3

그리고, 흐뭇하게 $vnet3 변수에 담긴 서브넷의 정보를 확인하면, 위의 2번 그림과 같은 상황이 발생합니다.

결론적으로, $vnet3 변수에 담아 놓은 정보는 Set-AzureRmVirtualNetwork으로 업데이트하기전의 결과이므로, 다음 명령으로 다시 한번 값을 업데이트 해줘야, 나중에 정확한 값을 사용할 수 있는 것입니다.

$vnet3=Get-AzureRmVirtualNetwork -Name 'AzureBCKor02-VNet1' -ResourceGroupName $rg2.ResourceGroupName


 


Comment +0

최근에(2018/01/24일자로 기억하지만, 정확하지는 않음) Azure Service Fabric을 만드는 과정에서 설정하는 [보안] 설정에 변화가 있었습니다.

기존에는 개발과 테스트를 위해  [unsecure]라는 옵션을 선택할 수 있었지만, 이젠 무조건 인증서를 사용한 보안 접속만 허용합니다.

따라서 이 글에서는 개발과 테스트용도로 사용할 때 자체 서명 인증서를 이용하는 방법을 설명합니다.


리소스 그룹과 키 자격 증명 모음(Key Vault) 만들기

먼저 Service Fabric과 키 자격 증명 모음(Key Vault)을 관리할 리소스 그룹을 만듭니다.

여기서 사용할 리소스 그룹의 이름은 'mymicroservice-kdk'로 하겠습니다.


1. 허브에서 [리소스 그룹]을 선택하고 오른편 창 상단에서 [추가]를 클릭합니다.


2. 리소스 그룹 이름을 입력하고 리소스 그룹 위치(여기서는 '일본 동부')를 선택하고 [만들기]를 클릭합니다.




이제 키 자격 증명 모음을 만듭니다.


3. 허브에서 [새로 만들기]-[보안 + ID]를 선택하고 오른쪽 [추천]에서 [Key Vault]를 클릭합니다.


4. 다음 항목에 값을 입력합니다. 나머지는 기본 값으로 남깁니다. [만들기]를 클릭합니다.
- 이름: mymicroservicekv
- 리소스 그룹: 조금 전에 만든 그룹 사용
- 위치: 일본 동부




3. [키 자격 증명 모음]이 만들어지면, 허브에서 [리소스 그룹]-[키 자격 증명 모음]을 선택하고 키 자격 증명 모음 블레이드에서 [액세스 정책] 항목을 클릭합니다.


4. 오른편에 확장된 블레이드에서 [클릭하여 고급 액세스 정책 표시] 링크를 클릭한 다음, [배포를 위해 Azure Virtual Machines에 대한 액세스 사용] 확인란을 선택하고 [저장]을 클릭합니다.




Azure Service Fabric 만들기

이 글에서 다루는 주제인 Service Fabric 리소스를 만들어 볼 차례입니다.

Service Fabrice이 무엇인지 궁금하신 분은 다음 링크를 통해 Azure Service Fabric 개요를 살펴보시기 바랍니다.


1. 허브에서 [새로 만들기]-[계산]을 선택하고 오른쪽 [추천]에서 [서비스 패브릭 클러스터]를 클릭합니다.


2. [기본 설정 구성]에서 다음 항목에 값을 입력합니다.
- 클러스터 이름: mymicroservicesf-kdk
- 운영 체제: WindowsServer 2016-Datacenter
- 사용자 이름: steelflea
- 암호 / 암호 확인: Pa$$w0rd
- 리소스 그룹: 조금 전에 만든 그룹 사용
- 위치: 일본 동부


3. [클러스터 구성 설정]에서 노드 유형 개수를 1로 설정하고 [노드 유형 1]을 선택해 다음과 같이 설정합니다.
- 노드 유형 이름: Web
- 내구성 계층:
- 사용자 지정 끝점: 8082
- 초기 VM 확장 집합 용량: 5 (Azure 구독 유형에 따라 가능한 숫자가 다를 수 있습니다. 무료 체험 버전은 3으로 설정하세요.)




4. [클러스터 구성 설정]의 [가상 머신 크기] 항목을 선택하고 [D1_V2 표준]을 선택하고 [확인]을 클릭합니다.




5. [노드 유형 구성] 블레이드에서 [확인]을 클릭한 다음 [클러스터 구성] 블레이드에서 다시 [확인]을 클릭합니다.




6. [보안 설정 구성]에서 [Configuration Type]에 [Basic]을 선택합니다.


7. [보안 설정 구성][Key vault] 필수 설정 구성을 선택하고 조금 전에 만든 'mymicroservicekv'를 선택합니다.




8. [보안 설정 구성][Certificate Name]에 'mymicroservice-selfcert'를 입력하고 [확인]을 클릭합니다.




9. [검토, 템플릿 보기, 만들기]에서 "유효성 검사 통과"로 결정되면 [만들기]를 클릭해 서비스 패브릭 클러스터를 만듭니다.



Azure Service Fabric 연결을 위한 인증서 다운로드

관리 클라이언트에서 서비스 패브릭 클러스터에 보안 연결을 하려면 조금 전에 만든 mymicroservice-selfcert 인증서가 필요합니다.

이 인증서는 [키 자격 증명 모음]에서 다운로드 할 수 있습니다.


1. [리소스 그룹]에서 앞서 만든 'mymicroservice-kdk' 리소스 그룹을 선택하고 [mymicroservicekv] 항목을 클릭합니다.


2. [mymicroservicekv] 블레이드에서 [비밀]을 클릭하고, 앞서 만든 'mymicroservice-selfcert'를 선택합니다.




3. [mymicroservice-selfcert] 블레이드에서 [상태]가 '사용'인 현재 버전을 선택하면 확장되는 비밀 블레이드 맨 아래의 [인증서 다운로드] 버튼을 클릭해 적절한 위치에 저장합니다.




관리 클라이언트에 인증서 설치

이제 거의 마지막 작업에 가까이 왔습니다.

클라이언트 노드에 앞 단계에서 다운로드한 인증서를 설치하기 위해 MMC 스냅인을 사용합니다.


1. [Windows]+[R]을 눌러 [실행]창을 띄우고 'mmc'라고 입력한 다음 [확인]을 클릭해 [Microsoft Management Console]을 실행합니다.


2. [파일]-[스냅인 추가/제거] 메뉴를 클릭하면 실행되는 [스냅인 추가/제거] 창에서, [사용 가능한 스냅인] 항목 아래의 [인증서]를 선택하고 [추가]를 클릭합니다.




3. [인증서 스냅인] 창에서 [내 사용자 계정]을 선택하고 [마침] 버튼을 클릭합니다.




4. [스냅인 추가/제거] 창에서 [확인]을 클릭합니다.




5. 콘솔 화면의 왼편 창 [콘솔 루트]-[인증서-현재 사용자]-[신뢰할 수 있는 사용자] 항목을 마우스 오른쪽 클릭하면 표시되는 컨텍스트 메뉴에서 [모든 작업]-[가져오기]를 클릭합니다.




6. [인증서 가져오기 마법사]의 [인증서 가져오기 마법사 시작] 화면에서 [다음]을 클릭합니다.


7. [가져올 파일] 화면에서 [파일 이름] 텍스트 상자 옆 [찾아보기] 버튼을 클릭해 앞서 다운로드한 파일을 선택합니다 ([열기] 창에서 하단의 'x.509 인증서'가 선택된 드롭다운 버튼을 클릭해 '모든 파일'로 선택해야 인증서가 보인다). [다음] 버튼을 클릭합니다.




8. [개인 키 보호] 화면에서 [다음] 버튼을 클릭합니다.


9. [인증서 저장소] 화면에서 [인증서 저장소] 항목에 '신뢰할수 있는 사용자'가 선택된 것을 확인하고 [다음] 버튼을 클릭합니다.




10. [인증서 가져오기 마법사 완료] 화면에서 지정한 설정을 확인하고 [마침]을 클릭합니다.




11. 다시 콘솔 화면으로 돌아와서, 가져온 인증서가 보이는지 확인합니다.



12. 콘솔 화면의 왼편 창 [콘솔 루트]-[인증서-현재 사용자]-[개인용]에서 동일한 방식으로 인증서 가져오기를 한 번더 합니다.


Azure Service Fabric 클러스터 탐색기 보안 접속

이제 서비스 패브릭 클러스터를 만들고 인증서 준비까지 마쳤으므로 관리 클라이언트에서 서비스 패브릭 탐색기로 보안 연결이 되는지 확인해봅니다.


1. [리소스 그룹]-[mymicroservice-kdk]를 클릭하고 [mymicroservicesf-kdk]라는 이름의 서비스 패브릭 클러스터를 선택합니다.


2. [개요] 노드의 상단 [기본 정보] 섹션 아래 부분의 [Service Fabric Explorer] 링크를 클릭합니다.


3. 브라우저의 새 탭에서 보안경고(자체 서명 인증서를 사용하기 때문)를 뛰우지만, 아래의 [세부 정보]라는 링크를 클릭하면 추가 내용이 표시됩니다. 맨 아래 [웹 페이지로 이동]이라는 링크를 클릭합니다.




4. [인증서 확인] 창이 뜨면 [확인]을 클릭합니다.




5. [자격 증명 필요] 창이 뜨면 [허용]을 클릭합니다.




6. 잠깐 기다리면, 다음 화면과 같은 [Service Fabric Explorer] 화면을 만날 수 있습니다.

여기까지 왔다면, 이제 Azure Service Fabric을 사용할 준비가 끝났습니다.




Comment +0

이번 포스팅은 On-premise에서 사용중인 DB 서버의 가용성 문제로 애플리케이션의 DB 서비스를 Microsoft Azure SQL 서버로 마이그레이션했던 과정을 정리한 것입니다.

 

글에서는 On-premise에서 사용하던 DB 서버인 MS SQL Server 2012에서, SSMS(SQL Server Management Studio) 사용하여 Azure SQL 서버로 데이터베이스를 마이그레이션 합니다.

 

Azure SQL 데이터베이스는 PaaS 입니다. 이미 오랫동안 입증된 SQL 서버 기술을 통합해 클라우드에서 완벽하게 관리되는 관계형 데이터베이스 서비스를 플랫폼으로 제공하는 것입니다. 하드 드라이브와 서버, 스토리지와 같은 물리적 하드웨어는 Microsoft에서 관리하지만 데이터베이스 인스턴스와 관련 로그인, 사용자 그리고 역할  등은 서비스 이용자가 관리할 있습니다.

 

On-premise 데이터베이스를 Azure 마이그레이션 하기 위해서는 먼저 Azure SQL DB 인스턴스를 먼저 만들어야 합니다.



Azure SQL 데이터베이스 만들기


먼저, Windows Azure 포털에 로그인 합니다. 

다음 그림에서처럼 포털의 왼편 하단 메뉴에서 [SQL 데이터베이스] 선택합니다.



 가운데 상단에서 [추가] 단추를 클릭하면, 다음 그림과 같은 화면이 나옵니다.




여기서 입력할  항목은 다음과 같습니다. 빨간색 * 표시는 반드시 입력해야 하는 값입니다.


☞ 데이터베이스 이름:  프로그래밍에서 사용하거나 SSMS, Visual Studio에서 연결할 데이터베이스 이름 입니다.

구독: MSDN 구독이 있는 경우.
리소스 그룹: (만든 적이 없는 경우) 리소스 그룹 이름을 입력합니다.

소스 선택: 백업 등이 있으면 선택할 있습니다. (여기서는 데이터베이스)

서버: 기존에 만든 서버가 없다면 새로운 서버를 만듭니다. 이후에 데이터베이스를 추가할 동일한 서버 하위로 추가할 있습니다. 서버 이름과 서버 관리자 로그인, 암호, 서버의 위치 등을 결정합니다.


가격 책정 계층: 사용하려는 데이터베이스의 예상되는 트랜잭션을 기준으로 선택합니다. 나중에 변경할 있습니다. 다음 그림은 가격 책정  계층의 일부를 나타낸 것입니다.



데이터 정렬: 기본 값을 사용합니다. 값을 변경하는 경우의 영향에 관해 미리 숙지하고 변경해야 합니다.


이제 최종적으로 입력한 정보는 다음 그림과 같습니다.



하단의 [만들기] 단추를 클릭하면 다음 그림처럼 배포가 시작됩니다.



배포가 완료되면 대시보드에서 만들어진 데이터베이스 클릭하여 다음과 같은 설정화면으로 들어갈 있습니다.



설정 화면에서 "데이터베이스 연결 문자열 표시" 링크를 클릭하면 다음 그림처럼 데이터베이스 연결 문자열을 얻을 있습니다. [데이터베이스 연결 문자열] 창에서 환경에 맞는 문자열 표시 상자 오른 편의 단추를 클릭하면 클립보드로 복사됩니다.



예를 들어, ADO.NET 경우는 다음과 같은 샘플 문자열을 얻을 있습니다.


Server=tcp:transwriting.database.windows.net,1433;Database=mydb;User ID=dbadmin@transwriting;Password={your_password_here};Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

 

여기서 {your_password_here} 부분에 조금 전에 만든 암호를 입력해서 사용합니다.



 SSMS 사용한 데이터베이스 마이그레이션


이제 On-Premise SQL 서버로 와서 SSMS 시작하고 로그인 합니다.

SSMS에서 마이그레이션하려는 데이터베이스를 오른 클릭한 [태스크] 선택하면 컨텍스트 메뉴에서 [Windows Azure SQL 데이터베이스에 데이터베이스 배포]라는 메뉴를 확인할 있습니다. 메뉴를 클릭합니다.



이제 데이터베이스 배포 마법사가 시작됩니다.



[다음] 클릭하고 조금 전에 반은 Azure SQL 서버에 연결을 하면 많은 경우 다음과 같은 연결 에러 화면을 만나게 됩니다. 원인은 SSMS에서 Azure SQL 인스턴스로 액세스할 Azure에서 해당 접근에 대한 방화벽 예외를 주지 않았기 때문입니다.



다시 Azure 포털로 돌아가서  이전에 만든 Azure SQL 서버를 클릭하면 나오는 화면에서 "방화벽 설정 표시" 링크를 클릭하면 펼쳐지는 창에서 필요한 예외 정보를 입력합니다.



설정이 끝난 다시 SSMS 배포 마법사 화면으로 돌아와 다시 연결을 시도하면 정상적으로 연결이 되는 것을 확인할 있습니다.  이후 입력할 정보는 다음과 같습니다.



☞ 새 데이터베이스 이름: Azure SQL 서버에 추가로 만들 데이터베이스 이름을 넣습니다.

Windows Azure SQL 데이터베이스 설정: Azure SQL 가격책정 계층을 선택하는 입력 항목입니다.


모든 정보를 정확히 입력했는지 확인하고 [마침] 클릭합니다.




여기까지 왔다면 모든 작업이 순조롭게 완료됩니다. 끝나고 나면 SSMS Visual Studio에서 방금 만든 Azure SQL 데이터베이스 인스턴스에 연결할 있습니다.




Comment +0

RSMT(Remote Server Management Tools) Azure 포털과 같은 인터페이스로 제공하는 관리 도구입니다.  아직은 Preview 상태이며, Azure에서 리소소 추가("서버 관리 도구" 검색) 통해 설정할 있습니다.

 

RSMT 구성한 인터페이스로 NanoServer, Server Core 그리고 Server With GUI 관리할 있습니다. RSMT에서 지원하는 주요 관리 영역은 다음과 같습니다.

 

-시스템 구성 확인 변경

-프로세스와 서비스 관리

-리소스 사용에 대한 성능 확인

-이벤트 로그 확인

-설치된 역할과 기능 확인

-PowerShell 콘솔을 사용한 관리 자동화

 

RSMT 구성하면 다음 그림에서 보인 네트워크 연결 레이아웃처럼 Azure Public Cloud 내의 서버와  On-Premise 서버를 관리할 있습니다.  RSMT 게이트웨이를 통해 라우트 되기 때문에 구성할 RSMT 게이트웨이 서버가 별도로 필요합니다. 이미 동일한 리소스 그룹에 만든 게이트웨이가 있다면 게이트웨이를 선택해주면 됩니다.



 

지금 부터 간단하게 RSMT 구성하는 단계를 설명합니다. 편의상 Azure 상에 관리 대상 서버가 있으며, 게이트웨이와 동일한 리소스 그룹을 사용하는 것으로 봅니다. 또한 게이트웨이 서버와 관리 대상 서버는 워크그룹으로 사용되는 것으로 가정했습니다.


1. Azure 포털에 로그인하고 Test-GW(Server With GUI, Windows Server 2016 TP4) Test-Nano라는 대의 가상 머신을 만들었습니다.

 



2. 이제 RSMT 구성하기 위해 [모든 리소스] 메뉴에서 [추가] 단추를 눌러 다음 그림처럼 "서버 관리 도구" 검색하고 아래 결과 창에서 항목을 선택 합니다.



3. 오른편에 관련 정보와 구성도가 있는 화면이 표시되며 아래로 내려 [만들기] 단추를 클릭합니다.


4. [서버 관리 도구 연결 만들기] 창에서 필수 항목을 모두 채웁니다.
이때 주의 사항은 [컴퓨터 이름 항목] 도메인 환경이 아니라면 관리 대상 서버의 IP주소를 입력해야 합니다.  또한 게이트웨이 서버를 처음 설정하는 경우라면 [ 서버 관리 도구 게이트웨이 만들기] 항목에 미리 만들어 놓은 게이트웨이 서버 이름을 넣습니다.



5. 모든 정보를 정확히 넣었다면 아래 [만들기] 단추를 클릭합니다. 대시보드에서 서버 관리 도구가 배포되는 것을 확인할 있습니다.


6. 서버 관리 도구 배포를 완료한 해당 서버 관리 도구를 선택하면 다음 그림처럼 게이트웨이를 검색하지 못했다는 알림을 있습니다. 게이트웨이 서버에 필요한 소프트웨어 구성이 끝나지 않았기 때문입니다. 알림 메시지 내용 클릭합니다.


7. 이제 [게이트웨이] 구성이라는 새로운 창이 하나 펼쳐졌습니다. 여기서 게이트웨이 서버에 설치한 패키지 링크를 제공합니다. 중간 쯤에 보이는 [패키지 링크 생성]이라는 단추를 클릭하면 바로 아래 URL 채워집니다. URL 복사해서 브라우저에 던지면 압축 파일을 하나 받을 있습니다.


8. 다운 받은 압축 파일을 게이트웨이 서버로 복사하고 풀어보면 실행 프로그램 하나와 json 구성 파일 하나가 있습니다. GatewayService.msi 더블클릭해서 설치를 진행해줍니다. 별도로 설정할 정보가 없기 때문에 까지 [다음] 눌러주면 됩니다.


9. 프로그램이 정상적으로 설치되었다면 서비스에서 "Server management tools gateway"라는 항목이 생기고 실행 상태임을 확인할 있습니다.


10. 이 포스팅의 시나리오에서 워크그룹 환경을 가정했기 때문에 게이트웨이 서버와 관리 대상 서버의 신뢰된 연결을 만들어 주어야 합니다. 따라서 TrustedHosts 목록에  IP 추가합니다, 관리 대상 서버가 여러 대라면 쉼표로 분리해서 IP 여러 넣습니다.


11. 다음으로 관리 대상 서버에 원격 PowerShell 세션을 연결해 WinRM 서비스에 대한 방화벽을 열어두면 게이트웨이와 동일한 서브넷이 아닌 워크그룹 머신에도 연결할 있습니다.


12. 연결에 사용하는 계정이 로컬 Administrator 계정이라면 관리 대상 서버에서 다음 명령으로 정책을 활성화 시켜야 합니다.


13. 다시 Azure 포털로 돌아와서 배포된 서버 관리 도구를 선택해보면 알림 메시지가 변경된 것을 확인할 있습니다. 메시지의 지시 사항대로 바로 위의 [다음으로 관리]라는 단추를 클릭하여 관리 대상 서버에 연결할 계정 정보를 입력합니다.


14. 계정 정보가 정확하다면 관리 대상 서버에 연결되어 성능 정보 등을 받아오고 [설정] 창에서 필요한 작업을 있습니다.


 

아직 정식 출시는 아니지만 RSMT 통해 Windows Server 2016을 편리한 인터페이스로 관리할 있다는 점이 매력적입니다. 포스팅에서는 동일한 서브넷인 환경을 기준으로 했지만, 서브넷이 다른 경우에 대해서는 숙제로 남깁니다.

 

* 포스팅은 2016 2 24 있었던, TechNet Community 세미나의 "쉘을 통한 Windows Server 2016 관리" 세션의 내용을 보충하고자 작성한 것입니다.


Comment +0