Instalacja windows 2008 w istniejącym lesie z kontrolerami domeny windows 2003

Aby to uczynić należy skorzystać z narzędzia adprep. Aby zainstalować Windows 2008 w istniejącym lesie z kontrolerami domeny w wersji windows 2003:
adprep /forestprep
adprep /domainprep /gpprep

Narzędzie adprep znajduje się na płycie instalacyjnej z windows 2008 w katalogu \support\adprep

\support\adprep\adprep32.exe

Aby zainstalować Windows 2008 R2 (istnieje tylko wersja 64 bity) w istniejącym lesie z kontrolerami domeny w wersji Windows 2003:
adprep /forestprep
adprep /domainprep /gpprep

Narzędzie adprep znajduje się na płycie instalacyjnej z Windows 2008 R2 w katalogu \support\adprep\adprep32.exe

Poziom schematu (schema level) dla Windows  2008 to 44 dla Windows 2008 R2 to 47. Można go sprawdzić np w rejestrze:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
lub
"dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion"

Tutaj inne sposoby sprawdzenie schema level (http://support.microsoft.com/kb/556086)

wdsutil /bindpolicy - włączanie/wyłączanie wds na interfejsie sieciowym

Czasami zachodzi potrzeba chwilowego wyłączenia wds'a na danym interfejsie sieciowym - ja pracuję na środowisku w którym WDS ma 5 interfejsów sieciowych (każdy do innego vlanu). W naszym firmowym środowisku sieciowym oprócz WDS funkcjonuje rozwiązanie które służy do instalacji systemów z rodziny Linux. I kiedy potrzebuję zainstalować Linuxa w danej podsieci nie może odpowiadać na zapytania o serwer PXE - serwer WDS lecz system który jest odpowiedzialny za instalację Linuxów.

Łatwo możemy uzyskać opisany efekt poprzez narzędzie wdsutil:

• Żeby dodać interfejs do listy interfejsów na których nasłuchuje WDS:
  WDSUTIL /Set-Server /BindPolicy /Add /Address:  /AddressType:{IP|MAC}
• WDS słucha tylko na interfejsach z listy (exclude powoduje ze nasłuchuje na interfejsach które są poza listą) - wykonujemy to tylko raz!:
  WDSUTIL /Set-Server /BindPolicy /Policy:Include
• Żeby usunąć interfejs z listy interfejsów na których nasłuchuje WDS:
  WDSUTIL /Set-Server /BindPolicy /remove /Address:  /AddressType:{IP|MAC}

 Poniżej dwa screenshoty, pierwszy z nich kiedy na interfejsie w podsieci 192.168.171.0/24 nasłuchuje system inny niż WDS:

Poniżej po wykonaniu polecenia  wdsutil /set-server /server:wds-krk /bindpolicy /add /address:192.168.171.10 /addresstype:IP

 




 

Na uwagę zasługuje fragment pakietu DHCP: Next server IP address. Dodam, że DHCP nie działa na systemie Windows lecz na Linuxie i wszystko działa sprawnie

Przetwarzanie faz konfiguracji z pliku instalacji nienadzorowanej

1. WindowsPE – konfiguracja dysku, który obraz ma się ściągać z WDS

2. OfflineServicing – dodawanie poprawek do obrazu, paczek językowych lub sterowników

3. Specialize – klucz produktu, ustawienia sieciowe, ustawienia języka, nazwa komputera, UAC

4. Generalize – generowany jest nowy SID - wykonuje się tylko jeżeli uruchomiliśmy: sysprep /generalize

5. AuditSystem – wykonuje się tylko jeżeli logujemy się do trybu Audit

6. AuditUser – wykonuje się tylko jeżeli logujemy się do trybu Audit

7. oobeSystem – stosuje ustawienia systemu przed pojawieniem się Windows Welcome

Wyświetlania numerów zainstalowanych aktualizacji

Żeby wyświetlić numery zainstalowanych uaktualnień (na komputerze klienckim) można posłużyć się interfejsem WMI:

wmic qfe get hotfixid > fix.txt

i przekierować wynik do pliku tekstowego.

Jak sprawdzić gdzie dany proces zapisuje aktualnie dane?

Może się przydać np gdy serwer WSUS ściąga aktualizacje i nie widać tego procesu jako trwającej synchronizacji. Z pakietu SysInternals narzędzie procmon (Process monitor)

Rozwiązywanie problemów z nieprawidłowym plikiem instalacji nienadzorowanej unattended.xml

Właśnie skończyłem dodawać do WDS'a obraz instalacyjny Windows 7 w wersji 64 bitowej. Chciałem skorzystać z pliku odpowiedzi do instalacji nienadzorowanej, który udało mi się stworzyć już jakiś czas temu do wersji 32 bitowej systemu. Otworzyłem plik xml w Notepad++ wyszukalem i zamieniłem ciąg znaków "x86" na "x64" - jak się okazało w trakcje prób odtwarzania plik odpowiedzi był niepoprawny i dokładnie taka była treść komunikatu na komputerze na którym próbowałem odtworzyć system:

The provided unattend file [X:\sources\wdsunattend\wdsunattend.xml] is not a valid unattended Setup answer file

To co było niepoprawne w tak stworzonym pliku to ciąg znaków określający architekturę systemu "x64" - poprawnym określeniem jest amd64. Jak dowiedzieć się czegoś więcej na temat tego gdzie znajdują się błędy w takim pliku? Kiedy wyświetlony jest komunikat z błędem instalacja "czeka" - jeżeli klikniemy OK komputer uruchomi się ponownie, dlatego należy wcisnąć SHIFT+F10 - spowoduje to otworzenie się command line. Przechodzimy do katalogu X:\Windows\panther\ i tutaj znajdują się pliki xml oraz log w których możemy znaleźć więcej informacji na temat tego jakie błędy znajdują się w pliku odpowiedzi. I w tym konkretnym przypadku plik setuperr.log zawierał tekst:

Description = The processorArchitecture attribute has an has an invalid value.

Polecam narzędzie trace32 który znajduje się w pakiecie System Center Configuration Manager 2007 Toolkit V2 (http://download.microsoft.com/download/5/5/0/55078AC4-3D15-407B-948E-CEB72A0A5A50/ConfigMgrTools.msi) a które bardzo usprawnia proces przeglądania tego typu logów.

BITS - Background Intelligent Transfer Service

Krótka instrukcja jak szybko skorzystać z możliwości jakie daje nam BITS - usługa domyślnie zainstalowana w Windows 7 (tryb startu Manual):

W PowerShell importujemy moduł do obsługi BITS:
Import-Module BitsTransfer

Upload danych na udostepniony udział:
Start-BitsTransfer -Source file.txt -Destination \\client\share -Priority normal

Download (np Serice Pack)
Start-BitsTransfer http://download.microsoft.com/download/a/c/7/ac78df4d-59cc-4e25-b4d7-94598a149719/WindowsXP-KB835935-SP2-PLK.exe C:\winXPsp2.exe -Priority low