Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

smigdeploy.exe를 이용한 Windows Server 2016에서 2019로 마이그레이션 방법

Azure에서의 VM은 in-place 업그레이드가 가능하지 않으므로,

Performing an in-place system upgrade is not supported on Windows-based Azure VMs
; https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/in-place-system-upgrade

다른 방법을 사용해야 합니다.

Method 1: Deploy a newer system and migrate the workload
Method 2: Download and upgrade the VHD

이 중에서 VHD를 다운로드해 변경 후 업그레이드하는 것은 자칫 수백 GB 단위의 데이터가 오고 갈 수 있으므로 불편할 수 있습니다. 그래서 "Windows Server migration tools"를 제공해 준다고 하니 이쪽을 기웃거리게 되는데요, ^^;

Windows Server Migration Tools Installation, Access, and Removal
; https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd379545(v=ws.10)

이름에서 느껴지는 그동안의 "마이그레이션 도구"에 대한 관행과는 달리 이게 클릭 몇 번으로 수행되는 방식이 아니라 좀 불편합니다. 일단, 한 번 어떤 식인지 따라가 볼까요? ^^




우선, 환경을 다음과 같다고 가정했을 때,

기존 서버: Windows Server 2016 (IP: 192.168.100.5)
신규 서버: Windows Server 2019 (IP: 192.168.100.6)

2대의 서버에 모두 다음의 명령어로 "Windows Server Migration Tools" 구성 요소를 설치합니다.

Add-WindowsFeature Migration

자, 이제부터 자신이 원하는 구성 요소에 대해 "Windows Server Migration Tools"의 환경에서 실행할 수 있는 PowerShell 명령어를 구사하면 됩니다. 아마도 제일 먼저 할 일은, 기존 서버에 구성한 "Roles and Features"일 텐데요, 이것들을 마이그레이션 하기 위해 우선 그 기능들의 목록을 알아내야 합니다. 이를 위해 "기존 서버"에서 "Server Manager"의 "Tools" / "Windows Server Migration Tools" / "Windows Server Migration Tools"를 실행해 뜨는 PowerShell 환경에서 Get-SmigserverFeature 명령어를 실행하고,

// 참고: https://www.learnesl.net/migrating-roles-from-server-2012r2-to-windows-server-2016/

PS C:\Windows\system32> cd .\ServerMigrationTools
PS C:\Windows\system32\ServerMigrationTools> Get-SmigserverFeature

WindowsFeatureName ID            Installed
------------------ --            ---------
                   BranchCache        True
WoW64 Support      WoW64-Support      True

출력된 WindowsFeatures에 대한 "ID"에 대해 하나씩 설정을 export 해 줍니다.

PS C:\Windows\system32\ServerMigrationTools> Export-SmigServerSetting -FeatureID BranchCache -Path:C:\mig_settings\1

cmdlet Export-SmigServerSetting at command pipeline position 1
Supply values for the following parameters:
Password: *************

      ItemType ID          Success DetailsList
      -------- --          ------- -----------
WindowsFeature BranchCache    True {}

PS C:\Windows\system32\ServerMigrationTools> Export-SmigServerSetting -FeatureID WoW64-Support -Path:C:\mig_settings\2

cmdlet Export-SmigServerSetting at command pipeline position 1
Supply values for the following parameters:
Password: *************

      ItemType ID          Success DetailsList
      -------- --          ------- -----------
WindowsFeature WoW64-Support  True {}

그다음 이렇게 해서 출력된 디렉터리의 내용을 신규 서버로 보내고,

robocopy C:\mig_settings \\192.168.100.6\c$\mig_settings /S

신규 서버 환경에서는 마찬가지로 "Server Manager"의 "Tools" / "Windows Server Migration Tools" / "Windows Server Migration Tools"를 실행해 뜨는 PowerShell 환경으로 들어가 해당 설정들을 import 합니다.

Import-SmigServerSetting -FeatureID BranchCache -Path:C:\mig_settings\1 -verbose -Force
Import-SmigServerSetting -FeatureID WoW64-Support -Path:C:\mig_settings\1 -verbose -Force

// 이유는 알 수 없지만 제 환경에서 WoW64-Support의 경우에는 "The Windows feature with ID WoW64-Support cannot be imported to this server" 오류가 발생합니다.
// 사실, BranchCache나 WoW64-Support는 윈도우 서버가 기본적으로 Role을 구성하기 때문에 위와 같이 굳이 export/import할 필요가 없습니다.




물론, 마이그레이션 해야 할 것이 "Windows Features"만 있는 것은 아닙니다. 사용자 계정도 로컬에 만들었다면 신규 서버로 옮겨줘야 하는데요,

What is Windows Server Migration Tools and how to use it?
; https://www.ubackup.com/windows-server/how-to-use-windows-server-migration-tools-6988.html

Windows Features를 했을 때와 마찬가지로 Export-SmigServerSetting / Import-SmigServerSetting 명령어를 이용하지만 옵션이 달라집니다.

// 소스 서버
Export-SmigServerSetting -User All -Group -Path C:\SrcUsersGroups ?Verbose
robocopy C:\SrcUsersGroups \\192.168.100.6\c$\SrcUsersGroups /S

// 대상 서버
Import-SmigServerSetting -User Enabled -Group -Path C:\SrcUsersGroups -Verbose

(export/import 후에는 개별 사용자들이 모두 "User must change password at next logon", "Account is disabled" 되어 있기 때문에 필요하다면 이를 직접 활성화해야 합니다.)

참고로, SQL Server가 설치된 경우라면 다음과 같은 식의 오류가 발생하는데요,

VERBOSE: Warning 1379: Group Performance Monitor Users was not imported because the group already exists on the local
computer.
VERBOSE: Error 1379: Member NT SERVICE\SQLSERVERAGENT cannot be added to group Performance Monitor Users.
VERBOSE: Error 1379: Member NT SERVICE\MSSQLSERVER cannot be added to group Performance Monitor Users.

문제 될 것은 없지만, 저런 오류가 거슬리는 분들은 사용자/그룹을 마이그레이션하기 전에 SQL Server를 미리 설치해 두어야 합니다.




사실, 사용자/그룹 설정을 복사하는 것보다 더 중요한 것은 "User Profile"의 내용일 것입니다. 이에 대해서는 다음의 글에서 소개하고 있으니 참고하시고.

Windows Server ? Migrating Files / Folders / Shares / User Profiles
; https://www.petenetlive.com/KB/Article/0001201

그러니까, 남은 작업이라면 결국 응용 프로그램과 그에 대한 데이터를 마이그레이션 해야 하는데, 위에서 "SQL Server"에 대해 짐작할 수 있었겠지만 "Windows Server Migration Tools"에서는 응용 프로그램에 대한 마이그레이션은 지원하지 않습니다.

단지, "폴더"를 복사하는 기능을 Send-SmigServerData / Receive-SmigServerData의 조합으로 제공합니다. 방법은, "신규 서버" 측에서 Receive-SmigServerData 명령어를 실행시켜 둔 후,

PS C:\windows\system32\ServerMigrationTools> Receive-SmigServerData

cmdlet Receive-SmigServerData at command pipeline position 1
Supply values for the following parameters:
Password: *************

"기존 서버" 측에서 어떤 데이터를 보낼지 선택해 Send-SmigServerData 명령어를 실행하면 됩니다.

[형식]
Send-SmigServerData -ComputerName {destination-computer-name} -SourcePath {path-to-source-folder} -DestinationPath {path-to-destination-folder} -include all -recurse

[예제: 기존 서버의 c:\db 폴더를 신규 서버의 c:\db 폴더로 모두 복사]
Send-SmigServerData -ComputerName vm2 -SourcePath c:\db -DestinationPath c:\db -include all -recurse

그런데, (/SEC 옵션을 준) robocopy가 있는데 굳이 이 기능을 사용해야 할 이유가 있을까요? 왜냐하면, 파일 권한까지 (비교적) 잘 전달이 되기 때문입니다. 예를 들어, 기존 서버에 "kevin", "admin" 계정에 대해 권한을 준 것을 robocopy/SEC로 복사하면 다음과 같이 계정 정보가 깨지지만,

win_mig_tool_1.png

*-SmigServerData 명령어로 이전하면 계정 정보가 살아 있습니다.

win_mig_tool_2.png

(kevin 계정의 경우 "SeongTae Jeong" 계정으로 바뀌었는데 아마도 기존 서버의 로그인 계정이 "kevin"이었고, 신규 서버의 로그인 계정이 "SeongTae Jeong"이었으므로 그렇게 된 듯합니다.) 그래도 이상한 것은 "admin"이라는 계정의 아이콘을 보면 "x" 표시가 되어 있는데 이에 대한 의미는 잘 모르겠습니다.

그래도 기존 서버처럼 깨진 SID(security identifier) 형식이 아니라 마이그레이션 한 후에 적절한 계정으로 다시 대체할 수 있도록 식별이 가능하다는 점에서*-SmigServerData 명령어가 아주 의미가 없진 않을 것입니다.




보는 바와 같이 "Windows Server migration tools"가 그다지 이름값을 하고 있지는 않습니다. 따라서 이것을 이용하기보다는 네트워크 전송이 좀 부담이 되어도 "Method 2: Download and upgrade the VHD" 방법을 쓰는 것이 어찌 보면 가장 안전하고 쉽게 업그레이드하는 방법일 수 잇습니다. (그나저나, 애당초 Azure에서 in-place 업그레이드를 지원하면 될 텐데... 그걸 못해주네요. ^^;)





[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 3/9/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  [54]  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12287정성태8/5/20209995오류 유형: 636. C# - libdl.so를 DllImport로 연결 시 docker container 내에서 System.DllNotFoundException 예외 발생
12286정성태8/5/202010811개발 환경 구성: 501. .NET Core 용 container 이미지 만들 때 unzip이 필요한 경우
12285정성태8/4/202011201오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/4/202010453디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/202010947디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd) [2]
12282정성태8/2/20209684디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/202012271개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/202011418오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/202012292개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/20209600VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/202011100개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/202010384.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/202012868개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/202012263개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/202013914개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/20208871.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙 [2]파일 다운로드1
12271정성태7/16/202010917.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/202011719오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/20208662오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/202010838오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/202012505.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/202010232오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/20209357오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/202018463오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
12261정성태7/9/202011391VS.NET IDE: 148. 윈도우 10에서 .NET Core 응용 프로그램을 리눅스 환경에서 실행하는 2가지 방법 - docker, WSL 2 [5]
12260정성태7/8/20209704.NET Framework: 926. C# - ETW를 이용한 ThreadPool 스레드 감시파일 다운로드1
... 46  47  48  49  50  51  52  53  [54]  55  56  57  58  59  60  ...