OSD 배포의 WinPE 단계에서 사용자가 컴퓨터 이름을 입력 할 수있는 양식을 시작합니다. PS 스크립트의 일부를 가져와야하는 ActiveDirectory 모듈이 필요하지만 AD 모듈을 가져올 수 없습니다.
Import-Module (Join-Path $(Split-Path $env:SMS_ADMIN_UI_PATH) ConfigurationManager.psd1)
Import-Module ActiveDirectory
Import-Module ActiveDirectory
$ADSites = (Get-ADReplicationSite -filter *).Name
Boot.Wim 파일에 PowerShell 모듈을 추가하고 복사했습니다.
WinPE는 일반적인 Windows가 아니며 Active Directory 커맨드 렛은 매우 특별하므로 (비 서버 OS에서 작동하려면 설정이 필요합니다) 이것은 잘못된 조합입니다.
iRon이 언급했듯이 이것을 포함하는 방법이 있지만 항상 지원되지 않는 해킹입니다. PE 버전이 변경되면 다른 파일로 수행해야 할 수도 있고 ne 버전이 해킹을 완전히 깨뜨릴 수도 있습니다. OSD를 위해 이와 같은 것에 의존해서는 안됩니다. (특정 AD 설정에 대해 잘 모르지만 대부분의 경우 PE 변경 사항을 항상 유지하는 것보다 스크립트에 도메인 이름을 하드 코딩하고 각 사이트 추가에서 스크립트를 업데이트하는 작업이 훨씬 적습니다. 설계 상 1 년에 3 번)
모듈없이 작동하는 모든 AD 관련 항목에 대한 폴백은 PE에서 작동 할 수있는 adsi입니다 (일반적으로 Powershell이 작동하려면 부팅 이미지를 변경해야하지만 이러한 변경 사항은 SCCM에서 지원되므로 릴리스 변경에 대한 추가 작업을 제공하지 않습니다) 그리고 당신은 아마 여기까지 왔을 것입니다)
adsi를 사용하면 다음과 같은 사이트 목록을 얻을 수 있습니다.
$sitesDN = "LDAP://CN=Sites," + $([adsi] "LDAP://RootDSE").Get("ConfigurationNamingContext")
$ADSites = (([adsi]$sitesDN).psbase.children | where {$_.Objectclass -ieq "site"}).Name
참고로이 코드가 필요한 다른 사이트가 있다고 가정합니다. 이것이 AD 설정에 관계없이 작동하기 때문에이 방법이 "골드 표준"이되는 경우 중 하나이지만 개인적으로 변경 될 가능성이없는 사이트가 하나만있는 경우 (많은 사람들이 갖고있는 것처럼) 나는 반대하는 것이 좋습니다. 안전하고 이름을 하드 코딩하더라도 복잡한 솔루션입니다. PE는 특수한 경우가 많고 때로는 디버깅하기가 어렵 기 때문에 가능하면 복잡성을 줄이십시오 (물론 동일한 편의성을 유지하는 한).
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다