Skocz do zawartości

Tworzenie własnego recovery


Rekomendowane odpowiedzi

Witam. Chcę stworzyć własną partycję recovery i pracuję na bazie tego postu: https://www.fixitpc.pl/topic/596-system-recovery-prawie-profesjonalnie-i-kompleksowo/

Bazuję głownie na tym skrypcie: autounattend.xml

 

Ale mam kilka problemów których nie potrafię sam rozwiązać:

 

1. Jaką dodać linijkę żeby zainstalowały mi się dodatkowe programy tuż po pojawieniu się pulpitu bądź tuż przed pojawieniem się? Dodam że są to głownie pliki .exe (pliki znajdowały by się na płycie, usb bądź partycji recovery windowsa, w planach być może tworzenie płyt recovery zamiast partycji)

2. Czy podczas przywracania recovery nie zostanie sformatowana partycja recovery? Jeśli tak to jak przerobić skrypt żeby tego nie robił?

3. Jak dodać dodatkowe sterowniki do instalacji windows, bądź recovery?

 

Bardzo proszę o pomoc w tych kwestiach.

 

Pozdrawiam

Odnośnik do komentarza
Pomoc jest darmowa, ale proszę rozważ przekazanie dotacji na utrzymanie serwisu: klik.

Troszkę mylisz pojęcia moim zdaniem, oddzieliłbym proces instalacji systemu od procesu tworzenia recovery. To podczas instalacji należy sobie zainstalować sterowniki i programy dedykowane dla danej maszyny a następnie złapać recovery. Z prywatnej wiadomości odniosłem wrażenie, że chcesz utworzyć obraz do przenoszenia między maszynami - nie do tego służy recovery, z zasady jest to obraz spersonalizowany dla danej maszyny, oczywiście można w pewnych warunkach uzyskać obraz uniwersalny pod warunkiem, że same maszyny nie różnią się zbytnio konfiguracją.
 
Odnośnie procesu instalacji proponuję sięgnąć po metodę opisaną w tym cyklu:
https://www.fixitpc.pl/topic/31405-instalacja-systemu-z-plików-wim-zautomatyzowana/
 
Jest ona na pewno wygodniejsza i szybsza od standardowego setupu od MS zwłaszcza jeżeli proces instalacji wykonujemy dość często, myślę że wygodny system instalacyjny może skutecznie zastąpić recovery.
Recovery ma jedną zasadniczą wadę, jego "aktualność" jest ściśle związana z momentem jego utworzenia, przywrócony system z reguły wymaga odświeżenia (windows update, sterowniki, również oprogramowanie), jeżeli natomiast zadbamy o nasze repozytorium instalacyjne to możemy mieć zawsze pod ręką świeży system, nie wymagający zbytniej atencji po postawieniu w przeciwieństwie do recovery.
Oczywiście dbanie o "świeżość" repozytorium jest zajmujące (i przy wielu wersjach systemu bardzo czasochłonne), wszystko zależy jak często musimy sięgać po reinstalację i jak wielu maszyn to dotyczy.
 
Podsumowując:
recovery > przywiązujemy do komputera, sterowniki i programy instalujemy przed złapaniem recovery, prawidłowo przygotowane recovery nie "niszczy" się po przywróceniu.
Instalacja > jeżeli chcemy mieć system aktualny nie sięgamy po recovery ale po świeżą instalację a skupiamy się na dbaniu o aktualność repozytorium.
 
Trudno napisać jakąś uniwersalną receptę na instalację programów w sposób zautomatyzowany, niestety niezależnie od faktu czy nasz soft będzie bazował na zunifikowanych pakietach instalacyjnych (np. innosetup) niestety przełączniki dotyczące silent install będą się znacząco różniły, nie da się zagadnienia sprowadzić do "instalacji programów" jest to raczej zagadnienie "instalacji programu".
Niestety trzeba się skupić na konkretnych pakietach i szukać dokumentacji dla konkretnego programu.
 
Ze sterownikami jest troszkę łatwiej - mamy tu pewną standaryzację (oczywiście są wyjątki, ale dotyczą one nie tyle sterowników co pakietów im towarzyszących).
Same sterowniki możemy dodać w dwóch trybach które podzieliłbym na: sterowniki dodawane w fazie preinstalacji (zintegrowane z obrazem wim lub - lepiej - zintegrowane z obrazem offline) i druga faza postinstall (dodane z użyciem mechanizmów unattend i mechanizmów systemu - pnpinst lub dpinst).
Dpinst sprowadza się do wrzucenia na dysk lokalny repo sterowników i wywołaniu odpowiedniej komendy, reszta zrobi się sama (musimy tylko zadbać o to żeby repo nie zawierało pakietów konfliktujących ale z doświadczenia wiem, że to rzadko się zdarza).
Są to skomplikowane zagadnienia a ja nie czuję się na siłach (zwłaszcza w sposób zrozumiały dla laika) tego opisywać, myślę że trzeba by tu przygotować prezentację i skupić się w niej na konkretnym scenariuszu. Nie będę zahaczał o integrację sterowników w trybie "pre" dość napisać że mowa o integracji z użyciem dism i nie ma problemu ze znalezieniem dokumentacji w sieci natomiast w fazie post z użyciem unattend jest banalnie proste.
Po pierwsze w fazie winpe umieszczamy odpowiedni pakiet na partycji instalacyjnej a do pliku odpowiedzi dodajemy wpis (bodź dwa zakładając, że chcemy posprzątać), oba w fazie "obbe" albo (co ja preferuję) pierwszy w fazie "specialize":
 

- <component name="Microsoft-Windows-Deployment" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
- <RunSynchronous>
- <RunSynchronousCommand wcm:action="add">
  <Order>1</Order>
  <Path>%systemdrive%\tmpdrive\$WinPEDriver$\x86\dpinst.exe</Path>
  <Description>Instalacja sterowników</Description>
  </RunSynchronousCommand>
  </RunSynchronous>
  </component>

i sprzątanie:

- <SynchronousCommand wcm:action="add">
  <Order>10</Order> 
  <Description>Oczyszczanie</Description> 
  <RequiresUserInput>false</RequiresUserInput> 
  <CommandLine>cmd.exe /c rmdir /s /q %systemdrive%\tmpdrive</CommandLine> 
  </SynchronousCommand>

samemu dpinst towarzyszy bardzo prosta konfiguracja nakazująca przeszukać wszystkie podkatalogi w poszukiwaniu sterowników:

  <?xml version="1.0" ?> 
- <dpinst>
  <quietInstall /> 
  <enableNotListedLanguages /> 
  <legacyMode /> 
  <scanHardware /> 
  <suppressAddRemovePrograms /> 
- <search>
  <subDirectory>*</subDirectory> 
  </search>
  </dpinst>

To tyle.
Jeżeli po instalacji nadal interesuje nas recovery to można to zrobić dużo prościej niż to pisałem przed laty, bez uciekania się do vbs (który był dość kapryśny więc zawodny), dość napisać że całość sprowadza się do przygotowania dwóch obrazów pe (jeden jednorazowy dla łapania reco drugi dla przywracania) i prostego skryptu inicjującego, oczywiście do zagadnienia możemy jeszcze dołączyć kwestię czy pieczętujemy obraz (i problemy z kluczem instalacji i aktywacją które temu towarzyszą).
Nie chcę się rozpisywać na ten temat, to wymaga raczej artykułu (bądź uzupełnienia wcześniej przywołanego) zademonstruję tylko same przykładowe skrypty:
inicjacja procesu:

@echo off
@setlocal

@for /f "tokens=2" %%G in ('bcdedit /enum {default} ^| find /i "path"') do (set FW=%%G)
@for /f "tokens=2" %%G in ('^(echo lis vol ^| diskpart^) ^| find /i "Recovery"') do (@set r=%%G)

(@echo sel vol %r% & @echo ass letter=r) | @diskpart >nul

@timeout /t 5 >nul

@bcdedit -create {e0004d38-3e75-4ca4-8f0a-e3c63352415e} /d "System Recovery" -application osloader >nul
@if /i [%FW:~-4,4%]==[.exe] @bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} path \windows\system32\winload.exe >nul
@if /i [%FW:~-4,4%]==[.efi] @bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} path \windows\system32\winload.efi >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} device ramdisk=[r:]\Recovery\create.wim,{ramdiskoptions} >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} osdevice ramdisk=[r:]\Recovery\create.wim,{ramdiskoptions} >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} systemroot \windows >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} winpe yes >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} nx optin >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} bootmenupolicy legacy >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} locale pl-pl >nul
@bcdedit -set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} inherit {bootloadersettings} >nul

@bcdedit -create {ramdiskoptions} /d "ramdiskoptions" >nul
@bcdedit -set {ramdiskoptions} ramdisksdidevice partition=r: >nul
@bcdedit -set {ramdiskoptions} ramdisksdipath \Recovery\boot.sdi >nul
@bcdedit -deletevalue {ramdiskoptions} description >nul

@bcdedit /bootsequence {e0004d38-3e75-4ca4-8f0a-e3c63352415e} >nul

@timeout /t 5 >nul

::@net user administrator /active:no >nul
::@net user tempuser "" /add >nul
::@net localgroup administratorzy tempuser /add >nul

::@REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d 0 /f >nul
::@REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName /t REG_SZ /d tempuser /f >nul

@%windir%\System32\Sysprep\sysprep /oobe /reboot

@pause

@shutdown /r /t 10

@endlocal

W zależności czy pieczętujemy czy nie odhaczmy odpowiednie linijki (przykład zakłada, że wykonujemy go w trybie audytu więc przy braku pieczętowania musimy założyć konto użytkownika).
Poza tym dodaje on jednorazowy wpis do kontenera rozruchowego który odwołuje się do obrazu winpe (create.wim)

create.wim to czyste winpe z dodanym skryptem rozruchowym (można go podać jako startnet.cmd, można wywołać z winphesl.ini):
@echo off
@setlocal
@CHCP 852 >nul

@for /f "tokens=2" %%G in ('^(echo lis vol ^| diskpart^) ^| find /i "Recovery"') do (@set r=%%G)
@for /f "tokens=2" %%G in ('^(echo lis vol ^| diskpart^) ^| find /i "Windows"') do (@set w=%%G)

(@@echo sel vol %w% & @echo ass letter=w & @echo sel vol %r% & @echo ass letter=r) | @diskpart >nul


@mkdir r:\RecoveryImage
@del /S /F /A /Q w:\Users\Public\Desktop\capture.cmd >nul
@del /S /F /A /Q w:\Users\Public\Desktop\sp.xml >nul
@del /S /F /A /Q w:\Users\Public\Desktop\zap.cmd >nul

@dism /Capture-Image /CaptureDir:w:\ /imagefile:r:\RecoveryImage\install.wim /name:"Recovery image"

@del /S /F /A /Q r:\Recovery\create.wim >nul

@bcdedit /set {bootmgr} ExtendedInput 1 >nul
@bcdedit /set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} device ramdisk=[r:]\Recovery\restore.wim,{ramdiskoptions} >nul
@bcdedit /set {e0004d38-3e75-4ca4-8f0a-e3c63352415e} osdevice ramdisk=[r:]\Recovery\restore.wim,{ramdiskoptions} >nul

@for /f "tokens=2" %%G in ('bcdedit /enum {default} ^| find /i "recoverysequence"') do (@set custom=%%G)


@if /i not %custom%=="" (
@for /f "tokens=1" %%G in ('bcdedit /enum bootmgr ^| find /i "custom"') do (@bcdedit /deletevalue {bootmgr} %%G >nul)
@bcdedit /set {bootmgr} custom:0x0000000054000002 %custom% >nul
@bcdedit /set {bootmgr} customactions 0x0001000043000001 0x0000000054000001 0x000100003e000001 0x0000000054000002 >nul
) else (
@bcdedit /set {bootmgr} customactions 0x0001000043000001 0x0000000054000001 >nul
)

@bcdedit /set {bootmgr} custom:0x0000000054000001 {e0004d38-3e75-4ca4-8f0a-e3c63352415e} >nul

@echo Przechwytywanie zakoäczone.
@endlocal
@pause
@Wpeutil reboot

powyższy skrypt złapie recovery i podepnie pozycję rozruchową dla restore.wim wywoływaną klawiszem F9.

Wg tego samego schematu tworzymy restore.wim ze skryptem:
@echo off
@setlocal
@CHCP 852 >nul

@SET /P res=Czy przywr˘ci† obraz systemu (T czy N)?:
@if /i [%res%]==[T] goto :potwierdzenie
goto :eof

:potwierdzenie
@echo Uwaga - to wymaľe wszystkie dane na partycji z Windowsem!!!
@SET /P restore=Czy kontynuowa† (T czy N)?:
@if /i [%restore%]==[T] goto :przywracanie
goto :eof

@for /f "tokens=2 delims= " %%G in ('call dism /get-wiminfo /wimfile:r:\RecoveryImage\install.wim /index:1 ^| find /i "error:"') do (@set EL=%%G)

@if /i not [%EL%]==[] @echo Plik nie zawiera prawidowego obrazu & @goto :eof

:przywracanie
@for /f "tokens=2" %%G in ('^(echo lis vol ^| diskpart^) ^| find /i "Recovery"') do (@set r=%%G)
@for /f "tokens=2" %%G in ('^(echo lis vol ^| diskpart^) ^| find /i "Windows"') do (@set w=%%G)
(@echo sel vol %w% & @echo for fs=ntfs quick label=Windows & @echo ass letter=w & @echo sel vol %r% & @echo ass letter=r) | @diskpart >nul

@dism /Apply-Image /ImageFile:r:\RecoveryImage\install.wim /Index:1 /ApplyDir:w:\

@echo Przywracanie zakoäczone.

:eof
@endlocal
@pause
@Wpeutil reboot

Należy dodać, że pliki create.wim i restore.wim są uniwersalne, budujemy je raz i dodajemy sobie do repozytorium instalacyjnego

ps.
skrypty używają kodowania znaków 852 (właściwego dla konsoli) dlatego na forum wyświetlają krzaczki.

pzdr
Odnośnik do komentarza

Ok to zostawmy zautomatyzowaną instalację windowsa na boku. Z prywatnej wiadomości faktycznie bardziej mi chodziło o instalację ale nie o obraz do przenoszenia miedzy maszynami bo każda maszyna jest inna i wymaga różnych driverów czy dodatkowych programów. Bardziej mi zależny na partycji recovery, na tym że raz przygotowana maszynę użytkownik w prosty sposób będzie mógł w prosty i w domu sam sobie "naprawić" system.

 

Czy jeśli użyje tych skryptów powyżej to mi to zadziała czy jeszcze trzeba coś w nich zmienić? I chciał bym żeby po przywracaniu recovery nie tworzyło mi nowego usera tylko był ten który został stworzony przy instalacji systemu, bo robiłem próby na skryptach tych z przed kilku lat i jak przywracałem system to chciało mi tworzyć nowego użytkownika a ten z instalacji systemu zostawał bez zmian. I tym samym miałem dwa konta, jedno stworzone przy pierwszej instalacji na którym nic się nie zmieniło po przywróceniu recovery i drugie konto które powstało przy przywracaniu recovery. No i zależy mi na tym również by w tym recovery zostały programy i sterowniki które dogram po świeżej instalacji. A co do wad recovery czyli tego że po jakimś czasie programy, sterowniki czy też update będą nie aktualne z tym co będzie w sieci to nie problem, bo w tej chwili raczej większość programów sama się aktualizuję jak i sterowników. Wiem że update windowsa7 są dosyć meczące i duże ale to jak by już problem samego użytkownika, jeśli decyduje się na przywrócenie obrazu to musi się liczyć z tym że system nie będzie aktualny i że czeka go jeszcze trochę pracy po przywróceniu systemu. Ale najważniejsze będzie miał, czyli działający system z wgranymi driverami.

A co do tych plików create.wim i restore.wim, zrozumiałem z postu że same się stworzy po wykonaniu tych skryptów? I czy same się wgrają na partycje recovery czy będę musiał je wrzucić tam ręcznie? Co do samego przechwytywania obrazu robi to ten pierwszy skrypt? I no pytanie czy tworzyć partycje recovery w ten sposób jaki podał Pan kilka lat temu, czyli na początku dysku z ID 0x27? Oraz w jakiej kolejności mam uruchamiać te skrypty żeby wszystko zadziałało.

 

A no i testowałem również ten Pana skrypt z przed kilku laty z zastosowanie ghosta ale nie wiem czemu, nie chciało mi to w żaden sposób działać.

 

Wiem, że banalne pytania zadaję ale walczę z tym już 3 dzień, a największą nadzieje pokładam w Panu bo póki co najobszerniej Pan to opisał i wie o czym piszę i o co mi chodzi, a bardzo mi zależy na tym żeby to działało. Jest wiele innych możliwości w sieci do tworzenia recovery ale ta opisana przez Pana najbardziej mi odpowiada chociaż nie najprostsza. A zalerzy mi żeby to wyglądało jak najbardziej oryginalnie do tego co dają producenci sprzętu w raz zakupionym laptopem.

 

Pozdrawiam

Odnośnik do komentarza

Na początek tytułem wyjaśnienia - bliżej mi do Chama niż do Pana.

 

Już nie pamiętam wszystkich szczegółów dotyczących tych starych skryptów - nieszczególnie z nich korzystałem (co myślę o recovery chyba jasno przedstawiłem) natomiast świta mi jedno - należało je wykonać w trybie audytu wtedy konto się nie powtarzało, ew. można było pracować na koncie "temp" i użyć pliku odpowiedzi który je kasował.

 

Nowe skrypty z założenia są dużo prostsze, przede wszystkim działają na czystym winpe (nie wymagają obsługi skryptów itp.), oczywiście są one uniwersalne w kontekście całego systemu instalacji (wymagają odpowiedniego nazewnictwa), jeżeli zachowamy konwencję którą opisałem w artykule to są one całkowicie bezpieczne dla innych partycji systemu.

 

W założeniu takie skrypty łapią obraz ad hoc. nie ingerują w niego więc to czy system wstanie z użytkownikiem czy bez zależy wyłącznie od sposobu zamknięcia systemu, możemy pieczętować, pieczętować z plikiem odpowiedzi, zamknąć na czysto.

To też zależy od tego na jakim koncie pracujemy, ja preferuję przygotowanie systemu w trybie audytu i późniejsze zapieczętowanie tylko trzeba pamiętać, że to zeruje aktywację i wyrzuca klucz produktu (nie problem jeżeli to aktywacja OA), z tym że ja przygotowuję obrazy do klonowania (deploing) a nie reco sensu stricte.

 

Skrypt instalacyjny nie przewiduje automatyzacji reco, przewiduje tylko utworzenie partycji o określonym rozmiarze (w szablonie jest to 15GB) ale oczywiscie możemy sobie i ten aspekt oskryptować, np. taki skrpyt wykonany po instalacji jeszcze w trybie winpe:

@echo off

 

xcopy /cherky N:\unattend.xml W:\Windows\Panther

xcopy /cherky N:\capture.cmd W:\Users\Public\Desktop

 

xcopy /cherky W:\Windows\Boot\DVD\PCAT\boot.sdi R:\Recovery\

 

xcopy /cherky N:\create.wim R:\Recovery\

xcopy /cherky N:\restore.wim R:\Recovery\

 

(@echo sel dis 0 & @echo sel vol R & @echo remove) | @diskpart >nul

(@echo lis vol & @echo exit) | @diskpart

 

Przerzuci wszystkie niezbędne pliki na wcześniej przygotowaną partycję, mamy tutaj też kopiowanie pliku odpowiedzi dla trybu nienadzorowanego a capture.cmd to plik inicjujący który podałem wcześniej (znajdzie się na pulpicie).

 

pzdr

Odnośnik do komentarza

@del /S /F /A /Q w:\Users\Public\Desktop\sp.xml >nul
@del /S /F /A /Q w:\Users\Public\Desktop\zap.cmd >nul

 

Co to za pliki są? sp.xml i zap.cmd? Co ma się w nich znajdować?

 

 

@dism /Capture-Image /CaptureDir:w:\ /imagefile:r:\RecoveryImage\install.wim /name:"Recovery image"

przy tej komendzie wyskakuje mim że opcja capture-image jest nieznana

 

pzdr

Odnośnik do komentarza

Obrazy win najwygodniej edytować niezależnym narzędziem wimlib-imagex wg. shematu który opisałem w tym poście:

https://www.fixitpc.pl/topic/31405-instalacja-systemu-z-plików-wim-zautomatyzowana/#entry189262

 

oczywiście z właściwym skryptem, np.:

..\wimlib-imagex.exe update winpe.wim 1 --check --rebuild --command="add restore.cmd \windows\system32\restore.cmd"

..\wimlib-imagex.exe update winpe.wim 1 --check --rebuild --command="add winpeshl.ini \windows\system32\winpeshl.ini"

..\wimlib-imagex.exe optimize winpe.wim --check

wstawi nam do pliku winpe.wim skrypty restore.cmd i wywołujący go winpheshl.ini (oczywiście możemy pierwszy skrypt wstawić jako starnet.cmd i pominąć ten drugi ale taka wersja jest bardziej elastyczna, przydatne na przyszłość), żeby dopełnić całości winphesl wygląda tak:

[LaunchApp]

AppPath=x:\Windows\System32\restore.cmd

 

@del /S /F /A /Q w:\Users\Public\Desktop\sp.xml >nul

@del /S /F /A /Q w:\Users\Public\Desktop\zap.cmd >nul

 

Co to za pliki są? sp.xml i zap.cmd? Co ma się w nich znajdować?

To tajemnica!

No dobra niech będzie - to pliki do pieczętowania.

Pierwszy to prosta komenda która uwalnia nas od ręcznego wpisywania długiej komendy (pieszczenia lenia):

C:\Windows\System32\Sysprep\sysprep /generalize /oobe /unattend:C:\Users\Public\Desktop\sp.xml /reboot

 

Druga to plik odpowiedzi użyty podczas pieczętowania, system po zapieczętowaniu ponownie wykonuje fazy instalacyjne i tak jak przy pierwotnej instalacji możemy ten proces zautomatyzować.

Jak już pisałem ja preferuję pracę nad systemem w trybie audytu i zapieczętowanie a więc taki plik np. może służyć do ustawienia konta użytkownika i pominięcia ekranu oobe, np.:

 

 

 
<?xml version="1.0" encoding="utf-8" ?> 
<unattend
	xmlns="urn:schemas-microsoft-com:unattend">
	<settings pass="specialize">
		<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
			xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<InputLocale>0415:00001045</InputLocale>
			<SystemLocale>pl-PL</SystemLocale>
			<UILanguage>pl-PL</UILanguage>
			<UILanguageFallback>pl-PL</UILanguageFallback>
			<UserLocale>pl-PL</UserLocale>
		</component>
	</settings>
	<settings pass="generalize">
		<component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
			xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<SkipRearm>1</SkipRearm>
		</component>
	</settings>
	<settings pass="oobeSystem">
		<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
			xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
			<UserAccounts>
				<LocalAccounts>
					<LocalAccount wcm:action="add">
						<DisplayName>ktośtam</DisplayName>
						<Name>ktośtam</Name>
						<Group>Administrators</Group> 
						<Password>
							<Value>dwBpAGUAbABjAGUAdABhAGoAbgBlAGgAYQBzAEIBbwA=</Value>
								<PlainText>false</PlainText>
							</Password>
						</LocalAccount>
					</LocalAccounts>
				</UserAccounts>
				<AutoLogon>
					<Enabled>true</Enabled>
					<Username>ktośtam</Username> 

					<Password>
						<Value>dwBpAGUAbABjAGUAdABhAGoAbgBlAGgAYQBzAEIBbwA=</Value>
							<PlainText>false</PlainText>
						</Password>
					</AutoLogon>
					<FirstLogonCommands>
						<SynchronousCommand wcm:action="add">
							<Order>1</Order>
							<Description>antyeko</Description>
							<CommandLine>powercfg -setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>2</Order>
							<Description>antyeko1</Description>
							<CommandLine>powercfg -x -monitor-timeout-ac 0</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>3</Order>
							<Description>antyeko2</Description>
							<CommandLine>powercfg -x -disk-timeout-ac 0</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>4</Order>
							<Description>antyeko3</Description>
							<CommandLine>powercfg -x -standby-timeout-ac 0</CommandLine>
						</SynchronousCommand>
						<SynchronousCommand wcm:action="add">
							<Order>5</Order>
							<Description>antyeko4</Description>
							<CommandLine>powercfg -h off</CommandLine>
						</SynchronousCommand>
					</FirstLogonCommands>
					<OOBE>
						<HideEULAPage>true</HideEULAPage>
						<ProtectYourPC>3</ProtectYourPC>
						<SkipUserOOBE>true</SkipUserOOBE>
						<SkipMachineOOBE>true</SkipMachineOOBE>
						<NetworkLocation>Other</NetworkLocation>
					</OOBE>
					<VisualEffects>
						<FontSmoothing>ClearType</FontSmoothing>
					</VisualEffects>
				</component>
			</settings>
		</unattend>

 

Co ciekawe pliku nie trzeba wywoływać z sysprep-em ale można umieścić bezpośrednio w katalogu panther (czy to dla setup-u czy samego syspprep-a).

ps. Ciekawe czy ktoś zgadnie hasło :).

 

@dism /Capture-Image /CaptureDir:w:\ /imagefile:r:\RecoveryImage\install.wim /name:"Recovery image"

przy tej komendzie wyskakuje mim że opcja capture-image jest nieznana

Po prostu niewłaściwa wersja, tak jak pisałem przy systemie instalacji tak i tutaj warto sięgać po najnowszy pakiet czyli winpe dla systemu 10 (dostępne w pakiecie adk), jeżeli chcesz korzystać z winpe dla siódemki to trzeba pamiętać że dism nie obsługiwał obrazów wim i trzeba dodać do zestawu imagex (bądź wspomniany wcześniej wimlib-imagex) z odpowiednimi wywołaniami.

 

pzdr

Odnośnik do komentarza

Ok. Recovery jako tako działa, obraz się robi, przywracanie też, tylko muszę ręcznie przypisywać klawisz funkcyjny i plik bootowalny z partycji recovery. Najpierw muszę wskazać plik create.wim do stworzenia obrazu a potem po utworzeniu uruchamiam system i programem zmieniam na plik restore.wim. I jak tak zrobię to działa to. Ale nie przypisuję mi klawisza funkcyjnego F9, tzn coś przypisuje ale jak wciskam to wyskakuje mi błąd żeby włożyć dysk instalacyjny, zdj: Zdjęcie

 

Z menadżera rozruchu jak uruchomię Recovery gdzie wcześniej dodałem wpis programem to uruchamiają mi sie pliki .wim ale muszę zmieniać ręcznie przypisywanie danego pliku .wim

 

No i teraz jak uruchomić system w trybie audytu podczas instalacji, żeby przygotować system do obrazu bez konta użytkownika, albo może coś dopisać w tym pliku inicjacyjnym żeby usuwało stworzone konto przy instalacji windowsa? Tak żeby utworzyć obraz bez konta i utworzyć je dopiero po przywróceniu Recovery.

 

Oraz jak przekopiować wszystkie pliki w trakcie jeszcze winpe. Czy wystarczy skrypt który będzie się znajdował na USB razem z instalką windowsa i uruchamiany w pliku autounattend.xml?

 

A i podczas przechwytywania obrazu wyskakuje mi błąd: Zdjęcie

 

Oraz jakie zadanie wykonuję ta komenda?

@w:\windows\system32\reagentc /setosimage /path r:\RecoveryImage /target w:\windows /index 1

 

pzdr

 

 

ps. już wiem jak wejść w tryb audytu i jak usunąć tymczasowe konto :)

Odnośnik do komentarza

Reaent możesz pominąć, to jest systemowy mechanizm recowery, komendą ustawia się parametry uruchomienia dla winre.wim, można ustawić ścieżkę do winre, ścieżkę do obrazu systemu używanego w przywracaniu, parametry oem itp.

Tutaj się nie wykonuje bo mamy środowisko pe z dziesiątki i odwołujemy się do reagenta z siódemki. Wydaje mi się, że nie warto się bawić tym na siłę, jeżeli potrzebujesz tej dodatkowej funkcji można ją wymusić z systemu, składnia dla siódemki będzie troszkę inna.

 

 

Obrazki sugerują, że system rozruchowy nie może znaleźć odpowiednich plików więc albo nie ma do nich dostępu (odpowiednia partycja nie istnieje) albo nie ma na niej plików.

Tutaj wymagane jest małe wyjaśnienie, jak pisałem na wstępie zestaw oczekuje pewnej konwencji - w tym przypadku są to trzy partycje, pierwsza rozruchowa, startowa (czy jak się upiera MS systemowa) z kontenerem bcd, bootmgr itp., druga to oczywiście windows i trzecia to recowery, ine partycje - o ile istnieją - nie biorą udziału w zabawie. Partycje muszą zostać nazwane zgodnie z konwencją co gwarantuje, że mechanizm zastosowany w skryptach je rozpozna.

I teraz - wszystkie pliki odpowiedzialne za recovery muszą się znaleźć na partycji recovery, jeżeli umieścisz je na partycji boot to skrypt nie przypisze odpowiednio ścieżek.

the system cannot ....

sugeruje wprost, ze create.wim nie znajduje się na partycji przypisanej jako r: w ścieżce recovery.

 

Na tej partycji oprócz plików create.wim i restore.wim musi się też znaleźć plik ram dysku boot.sdi.

 

Wszystkie pliki powinien tam umieścić skrypt z postu

https://www.fixitpc.pl/topic/32342-tworzenie-własnego-recovery/#entry193666

 

o ile konwencja się zgadza (s:>boot, r:>recovery i w:>windows).

Brak plików w tej ścieżce powoduje, że wpisy bcd się nie wykonują.

 

Jeżeli pracujemy w trybie audytu to żadnym kontem się nie przejmujemy, pracujemy na wbudowanym koncie administratora które zostanie wyłączone po zapieczetowaniu, konta tymczasowego nie tworzymy i nie usuwamy.

Jeszcze raz przypominam, że pieczętowanie usunie klucz produktu i aktywację windowsa.

 

autounattend.xml jest specyficzną wersją pliku unattend.xml która może się znaleźć w głównym katalogu dowolnej partycji widzianej przez setup (może to być też płyta dvd, można go nawet wrzucić na partycję windowsa choć nie ma to sensu).

Setup wykona sekcję winpe z tego pliku po czym skopiuje go do windows\panther i reszta pliku wykonuje się już po restarcie z tej lokalizacji, o ile nie wskazaliśmy później naszego usb jako źródła dla jakiś skryptów to można je już wyjąć (nawet wskazane na wielu sprzętach).

Ale tutaj ponownie - moje skrypty korzystają z konwencji opisanej i zastosowanej w artykule o instalacji z wim i z punktu widzenia setapu ms są raczej bezużyteczne.

I znów dzięki konwencji wg. której oprócz odpowiednich partycji S,W,R mam też źródło N mogę wszystkie pliki i skrypty przekopiować wg. wzoru ze skryptu:

https://www.fixitpc.pl/topic/32342-tworzenie-własnego-recovery/#entry193666

 

Wszystkie wcześniej przygotowane pliki, skrypty itd. znajdują się w ścieżce N a ta już wedle uznania na usb (penie czy dysku), płycie (mało wygodne) czy w sieci (najwygodniej i działa najszybciej).

 

pzdr

Odnośnik do komentarza

Dziękuje Ci maggreg za pomoc i poświęcony mi czas, oraz cierpliwość w wytłumaczeniu wszystkiego. Na parę dni muszę pozostawić prace nad własnym recocery, jak wrócę do pracy nad tym i będę miał jakieś pytania mam nadzieję że pomożesz jeszcze w jakiś nie jasnościach. A jak jednak wszystko mi wyjdzie tak jak myślę i oczekuje już po tym co wiem, dowiedziałem i nauczyłem, to jak starczy mi wiedzy, cierpliwości, samozaparcia i zbiorę wszystko do kupy to może napiszę tutorial na podstawie tego co mi przekazałeś.

 

pzdr

Odnośnik do komentarza

Przy okazji dobry opis wykonania recovery z użyciem mechanizmu "provisioning packages".

 

https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/desktop/deploy-push-button-reset-features

 

Jest to taki system który pozwala nam utworzyć plik ze wszystkimi zmianami utworzonymi w systemie po instalacji i późniejsze jego wykorzystanie podczas resetu do stanu początkowego, można też plik zintegrować z przywracanym obrazem.

 

pzdr

Odnośnik do komentarza

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...