maggreg

Jest to błąd Rafała - bootmgr.exe jest plikiem potrzebnym jedynie w przypadku botowania z sieci, jest on plikiem domyślnie ładowanym wtedy przez windowsowy loader pxe. W twoim przypadku właściwy plik to bootmgr (bez żadnego rozszerzenia. ps technicznie plik bootmgr zawiera sekcję identyczną z bootmgr.exe, bootmgr wewnętrznie składa się z trzech sekcji - pierwsza to tzw stub czyli fragment ładowany bezpośrednio przez BIOS i dwie sekcje właściwe plikom wykonywalnym czyli tzw PE (Portable Executable).* Właśnie drugie PE jest w 100% odpowiednikiem bootmgr.exe z tym, że w obecnych edycjach pliku bootmgr ta sekcja jest spakowana ponieważ loader nie może przekroczyć rozmiaru 512 kB. W przypadku pliku bootmgr.exe funkcję dwóch pierwszych sekcji pełni plik pxeboot.n12 czyli loader PXE. * - na podstawie informacji z linku do packera bootmgr: link pzdr

W poście #76 link równoległego wątku umieściłem skrypt służący do instalacji systemów z linii Vista, jest to oczywiście zarówno obiecana wcześniej sekcja jak i rozwinięcie wersji którą opisywałem na poprzednim forum. Słowo wyjaśnienia - po co w ogóle budować skrypt służący do tego celu skoro instalator systemów z tej linii wystarczy przekopiować na pena i już działa a nawet sam MS przygotował narzędzie które tą "robotę" upraszcza? Otóż dwa słowa - elastyczność i automatyzacja. O ile przeciętny "Kowalski" niewiele skorzysta na takim zestawie (choć może go oczywiście stworzyć dla celów poznawczych) to będzie on nieocenionym ułatwieniem dla osób które tworzą różne scenariusze instalacyjne z preinstalacją programów i sterowników czy też mają do czynienia z oryginalnymi komputerami różnych producentów i chcą sobie zautomatyzować proces prekonfiguracji czy choćby w łatwy sposób wykorzystać mechanizm SLP bez potrzeby ręcznej podmiany plików. Oczywiście samo "menu" jest tylko narzędziem umożliwiającym takie zastosowanie natomiast samą funkcjonalność zyskamy dopiero tworząc odpowiednie pliki odpowiedzi dla instalacji nienadzorowanej czy też repozytoria z zestawami programów, tweaków itp. Wyjaśnienia wymaga też fakt istnienia oddzielnych sekcji dla systemów pierwszej generacji vistowatych (Vista i 2008) oraz generacji drugiej (Siódemka i 2008 R2), otóż okazuje się (wbrew temu co można by wywnioskować z dokumentacji pakietów waik czy opk), że nowy setup zupenie nie radzi sobie z instalacją starszych systemów i trzeba w przypadku Visty skorzystać ze starszych plików - co prawda faza WinPE instalacji przebiegnie prawidłowo ale już po restarcie przywita nas niestety błąd. Tak wygląda drzewo folderów współpracujące z tym zestawem pen - Seven_Installer - - seven_unattend - - - AOems - - - dp - Vista_Installer - - vista_unattend - - - AOems - - - dp Katalog Seven_installer (i analogicznie Vista_installer) zawiera pliki setupu odpowiednie dla danego systemu, najprościej użyć zawartości katalogu "sources" z płyty instalacyjnej danego systemu, co prawda wszystkie pliki i katalogi nie są potrzebne ale najprościej wrzucić całość, oczywiście kasujemy słynny plik ei.cfg, możemy też śmiało skasować pliki katalogowe poszczególnych edycji (pliki clg) które nie są potrzebne do instalacji, dodatkowo w przypadku siódemki nie jest wymagany plik boot.wim co pozwoli zaoszczędzić sporo miejsca, niestety Vista oczekuje istnienia tego pliku choć nie wykluczone, że można ją ogłupić plikiem pustym (raczej nie sięga do jego zawartości). Jeżeli chcemy używać jednocześnie setupu dla stacji roboczych i serwerów należy pamiętać o przekopiowaniu plików licencji dla obu zestawów, to którego setupu natomiast użyjemy nie ma znaczenia - różnica wystąpi tylko w kolorze tła i okienek instalacyjnych. Setup domyślnie również plików install.wim szuka w tym katalogu a nie w katalogu sources, niżej napiszę jak to można obejść. Katalogi seven_unattend i vista_unattend zawierają oprócz następnych podkatalogów również pliki xml będące włąsnie plikami odpowiedzi dla instalacji nienadzorowanej przy czym skrypt traktuje całość prostolinijnie i doda do menu każdy plik znajdujący się wewnątrz tego katalogu. W katalogu AOems (skrót od alternatywne Oem-s) znajdują się podkatalogi (tak podkatalogi a nie bezpośrednio pliki itp) których zawartość może zostać użyta jako alternatywne katalogi $OEM$ przy czy katalogi te nie zastępują głównej instancji tego katalogu ale dodają się do niego (a w przypadku zdublowanej zawartości nadpisują ją), scenariuszy wykorzystania tego mechanizmu jest dość dużo ja przedstawię niżej jeden współpracujący z konkretnym plikiem odpowiedzi. W katalogu dp znajdują się natomiast skrypty diskparta do zautomatyzowanej konfiguracji dysku, jest to w gruncie rzeczy zbędna, nadmiarowa funkcjonalność (samą konfigurację można wpisać w pliku xml) ale w pewnych konkretnych zastosowaniach przydatna. na pewno przydatna w instalacjach w których nie będziemy korzystać z pliku odpowiedzi. linki do zestawu - zawierają tylko strukturę katalogów i kilka przykładowych plików - wymagają użycia zestawu z postu #1 link: vista-seven lub vista-seven Obiecałem metodą na obejście ograniczenia źródła plików instalacyjnych wim (a także nawy), otóż w tym celu należy zbudować minimalistyczny plik plik odpowiedzi zawierający tylko źródło instalacji (w pełniejszych plikach odpowiedzi należy pamiętać o dodaniu odpowiedniej sekcji): <?xml version='1.0' encoding='utf-8'?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-Setup" 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"> <ImageInstall> <OSImage> <InstallFrom> <Path>%litera%\Seven_Installer\install_64.wim</Path> </InstallFrom> <WillShowUI>OnError</WillShowUI> </OSImage> </ImageInstall> </component> </settings> </unattend> W ścieżce docelowej deko przykładu wykorzystałem fakt, że skrypt startowy menu utworzył w systemie zmienną "%litera%" odpowiadającą punktowi montowania naszego pendriva, dzieki temu podajemy ścieżkę bezwzględną do pliku wim nie martwiąc się zagnieżdżeniem katalogów. W przykładzie mamy ścieżkę do pliku z obrazami systemów 64 bitowych a jednak w zmiennej processorArchitecture pliku odpowidzi mamy podane "x86" co może wydawać się pewną niekonsekwencją. Otóż wszystko jest w porządku, zmienna ta obliguje w jakim kontekście wykonywany jest dany przebieg a ponieważ my dopalamy setup z WinPE w wersji 32 bit to i kontekst dla fazy WinPe musi być taki sam. Oczywiście w przypadku pełniejszych plików odpowiedzi należy pamiętać, że już późniejsze fazy będą się w przypadku systemu 64 bit odbywać właśnie w takim kontekście i już od fazy "specialize" zmienna "processorArchitecture" przyjmuje postać "amd64" (lub o czym nie wszyscy wiedzą dla niektórych komponentów może to być też wow64). A oto przykład dość rozbudowanego pliku odpowiedzi - ze względu na jego długość zamknięty w klamrach: Po krótce - co ten plik robi? Po pierwsze ustawia konfigurację dysków, tworzy dwie partycje, systemową i startową z których jedna zostanie później zablokowana dla edycji przez nadanie znacznika OEM. Ustawia nam źródło jak i miejsce docelowe instalacji (\równo plik jak i konkretny obraz), pozwala na instalację sterowników massstorage dla fazy WinPE, następnie instaluje kilka programów (tutaj pakiet dla Vmware + dla przykładu flash player) oraz sterowniki z pomocą dpinst (dość dobra metoda, co prawda setup potrafi skorzystać z własnego mechanizmu ale z praktyki wiem, że dpinst daje większą pewność). Dalej ustawiamy informacje OEM które pojawią się we właściwościach systemu (w przykładzie przypisane do naszego forum) Dalej wyłączamy przywracanie systemu i UAC (to jak kto woli, ja domyślnie wyłączam) Ustawiamy opcje Internet Explorera - strona startowa i zachowanie, wyłącznie wizarda pierwszego uruchomienia itp. W tej fazie (specialize) podajemy też właściwy klucz aktywacyjny systemu (klucz podany w fazie WinPE jest tylko kluczem instalacyjnym służącym do wybrania konkretnego obrazu z pliku wim i może zostać pominięty, o ile w przypadku siódemki plik ten przechodzi dalej to w przypadku visty już nie i należy pamiętać o późniejszym jego podaniu). W następnej fazie (OOBE) mamy ustawione automatyczne logowanie na konto Administratora (ten plik odpowiedzi jest zbudowany z myślą o potraktowaniu go sysprepem dlatego nie jest stworzone inne konto) Tutaj też są instalowane programy i wprowadzone ustawienia które z różnych względów nie udają się we wcześniejszym etapie <RunSynchronous>, najczęściej to właśnie w tym etapie większość osób instaluje wszystko co nie koniecznie jest najlepszy scenariuszem, mój przykład w tym etapie ustawia temat (z wykorzystaniem rejestru ponieważ domyślny mechanizm ma błędy które uniemożliwiają pełną customizację), instaluję też przeglądarkę, ustawiam profil zasilania (w przykładzie wyłączamy wszystkie oszczędzacze przeszkadzacze). instaluję prawidłowy, zgodny z komputerem certyfikat oem (plik licencji), w ostatnim etapie robimy sprzątanko (jeżeli ten wpis nie zadziałą i na końcu zostały śmieci jest to sygnał, że któryś wpis instalujący programy zewnętrzne zawiódł - w przykładzie najczęściej zawodzi instalacja toolsów dla vmware która zależnie od wersji bywa bardzo kapryśna, pocieszające że na maszynie fizycznej nie trzeba tego instalować ). Na koniec ustawiamy sobie wszystko ta, żeby nas okienko OOBE nie męczyło. Plikowi oczywiście towarzyszy podkatalog AOem z odpowiednią zawartością - u mnie nazwany "fixit" a w nim typowe dla tego mechanizmu podkatalogi: "$$" którego zawartość ląduje w katalogu windowsa (tutaj mamy pliki oobe, plik z ustawionym tematem, pliki licencji, kursorki itp) oraz katalog $1 którego zawartość wyląduje w głównym drzewie partycji instalacyjnej windowsa, ta zawartość jest u mnie potraktowana jako katalog tymczasowy który pod koniec instalacji zostaje (powinien zostać) usunięty, zawiera on programy i starowniki w ścieżka które są podane w pliku odpowiedzi. myślę, że filmiki które postaram się niedługo wrzucić pokażą potęgę (i prostotę) takiego sposobu instalacji. pzdr

Pora na ostatni fragment instalerów systemów windows, tym razem będzie to skrypt służący znów do instalacji systemów serii XP ale w odróżnieniu od wersji poprzednio opisanej w tym przypadku pliki instalacyjne nie będą przechowywane w pliku wim tylko w katalogu. Technicznie katalog = zawartość folderu i386 z płyty instalacyjnej więc przygotowanie samego zestawu sprowadza się (w tym zakresie) do przekopiowania odpowiedniego folderu. Jest to rozwiniecie podstawowego instalera opisywanego przeze mnie dawniej na forum SearchEngines, tym razem jednak zdecydowałem się połączyć zalety tego rozwiązania z konstrukcją zastosowaną w instalatorach wim a mianowicie o ile pliki instalacyjne przechowywane są w formie natywnej to już samo menu jak i ścieżki do folderów i plików dodatkowych budowane są na podstawie plików konfiguracyjnych. Zdecydowałem się na taką zmianę uznając, że proste wylistowanie katalogów buduje dość ograniczone i mało elastyczne środowisko na dodatek niewiele automatyzujące proces w stosunku do ręcznego przeklikania składni w konsoli. A oto rzeczony skrypt: I linki zewnętrzne: menu_rc.hta lub menu_rc.hta I kilka obrazków: Menu główne z sekcją instalatorów budowaną na podstawie plików konfiguracyjnych: Sekcja wybranego systemu: I poszczególne opcje: Same opcje pokrywają się z tym co mieliśmy w przypadku instalacji z pliku wim, różnicą jest brak opcji "domyślnego klucza", zdecydowałem że w tym przypadku przy instalacji nadzorowanej mamy możliwość wpisania klucza a w razie czego możemy się posiłkować plikiem pid.inf do którego mamy dostęp bezpośredni natomiast wprowadzanie do kodu sekcji podmieniającej klucz byłoby kłopotliwe - sam kod byłby dość rozbudowany, dla pewności oparty o wyrażenia regularne. W stosunku do instalatorów wim - jak już pisałem - taka wersja posiada tą zaletę, że dużo prościej ją przygotować, ponieważ mamy dostęp do natywnego setupu można mieć też pewność, że możemy skorzystać z opcji upgradu lub instalacji nakładkowej (choć oczywiście te opcje z konsoli), wadą natomiast jest na pewno wolniejsze działanie na malowydajnych pamięciach flash oraz brak możliwości postawienia tą metodą windowsa 2000 (setup nie uruchomi się z winpe nowszego niż 1.6). To już koniec fragmentu poświęconego instalacją - wkleję jeszcze tylko skrypt łączący wszystkie wcześniejsze opcje razem (z opcją wyłączenia nieużywanych), zachęcam do własnych eksperymentów oraz oczywiście do dyskusji. Opis struktury katalogów dla tego zestawy w równoległym wątku w poście #6 link pzdr

Tym razem kontynuujemy wątek skryptów poświęconych instalacji systemów. Poniższy skrypt służy do instalacji systemów z lini NT60 (czyli Vista, Server2008, Seven, 2008 R2). Problematykę przygotowania odpowiedniego repozytorium jak i poprzednio opiszę w równoległym wątku, także samą sensowność skryptowania tych instalerów postaram się tam wyjaśnić, tutaj przedstawię sam skrypt i jego funkcje. A oto bohater niniejszego wywodu: wersje na zewnętrznych hostach: Menu_Vista.hta lub Menu_Vista.hta Sposób uruchomienia skryptu w przypadku winpe z domyślnie odpalaną konsolą jest taki sam jak we wcześniejszym opisie instalatorów dla lini XP. Pierwszy obrazek pokazuje podstawowe menu które w tym przypadku nie jest generowane automatycznie, oba batony są obligatoryjne (docelowy skrypt konsolidujący wszystkie wersje będzie zawierał znaczniki pozwalające na włącznie lub wyłączanie poszczególnych podprocedur - przynajmniej taki jest plan). Z pewnych względów które wyjaśnię w równoległym wątku musimy zastosować oddzielne instalatory dla wcześniejszej lini systemów - dlatego mamy dwa batony. A oto funkcjonalność jaka się za nimi kryje: 1' - Po pierwsze menu pozwala nam wybrać z listy jeden z predefiniowanych plików odpowiedzi dla instalacji nienadzorowanej - i to w zasadzie już byłoby powodem do zainteresowania się tym zestawem - reszta jest w bonusie. 2' - Alternatywny katalog $OEM$, katalog ten nie zastępuje swojego głównego odpowiednika ale dodaje się do niego (jeżeli zawartość wewnętrzna się zdubluje zostanie jednak nadpisana), ja osobiście używam tylko tych katalogów wybieranych z menu, katalog główny/domyślny pozostaje pusty (może w ogóle nie istnieć), dzięki takiej konstrukcji możemy stworzyć predefiniowane zestawy instalujące programy czy sterowniki a także tworzyć odpowiedniki nośników recovery dla różnych producentów nie kolidujące ze sobą (w najprostszej wersji katalogi mogą zawierać pliki licencji dla instalacji SLP) 3' - Pozycja pozwala użyć predefiniowanego skryptu do partycjonowania dysku, opcja przydatna jedynie wtedy kiedy używamy stałych szablonów, tak naprawdę wygodniej manipulować dyskiem poprzez plik instalacji nienadzorowanej. 4 - Autostart wymusza automatyczny reset środowiska WinPE po przejściu tego etapu przez setup - w przeciwnym razie skrypt powróci do menu głównego. Funkcjonalność teoretycznie niewielka w praktyce bardzo automatyzująca różne scenariusze instalacji i upraszczająca cały proces - oczywiście podstawą jest zbudowanie sobie zestawu odpowiednich plików odpowiedzi, raz wykonana praca będzie później bardzo procentowała. Opis przygotowania samego zestawu i kilka przykładów wkrótce w wątku równoległym, niedługo też postaram się zaprezentować video pokazujące jak w praktyce wykorzystać można moje narzędzia. Opis struktury katalogów dla tego zestawy w równoległym wątku w poście #5 link pzdr

Wygląda na to, że integracja service packa powyższą metodą generuje pewien problem, mianowicie przewidziane dla tego zadania metody wyczyszczenia plików tymczasowych nie radzą sobie z tym zadaniem. Mam na myśli komendę: dism /image:"ścieżka" /cleanup-image /spsuperseded Na tą chwilę aby wykonać czystą instalację trzeba i tak zainstalować taki system (np. wirtualnie) wejść w tryb audytu i wtedy wyczyścić offline (czyszczenie w trybie online zdaje się w ogóle nie działać), a później ponownie zapieczętować system (oczywiście z generalizacją) i ponownie przechwycić. Oczywiście ze względy na możliwość oskryptowania samej integracji wygodniejsze wydaje mi się najpierw integrowanie a potem instalacja, czyszczenie niż instalowanie systemu a następnie sp1 ale na tą chwilę wygląda na to, że trzeba się będzie trochę pobawić. A może ktoś próbował jakiegoś narzędzia typu 7lite - jak w nim wygląda zaśmiecenie? Dodatkowo zauważyłem, że zalecane oficjalnie czyszczenie narzędziem "oczyszczanie dysku" nie działa w ogóle bez względu na użytą metodę instalacji/integracji. ps. widzę, że na msfn kolega @TomecekGD nie uzyskał konkretnej odpowiedzi pzdr

Sterowniki dla XP podałem w jednym z moich toturiali. Podawałem też link do opisu przeróbki jaka trzeba wykonać aby zainstalować siódemkę (lub vistę - tu konstrukcja jest podobna) wraz ze wzmianką o zastosowaniu powyższej metody dla WinPE. Zasadniczo całość sprowadza się do zmiany trybu w jakim pracują i startują sterowniki USB w systemie. Odnośniki: Odnośnik do zewnętrznego artykułu Sterowniki USB MassStorage dal XP pzdr

Nie powinno być żadnych problemów. pzdr

Przy okazji tematu o integracji poprawek warto nadmienić, że razem z wyciekiem sp1 dla siódemki pojawiły się też metody na integrację ww z obrazem/obrazami systemu. Ze wszystkich propozycji warto wymienić tą opisaną przez @Stannieman na sławnym (a może niesławnym ) forum mydigitallife w temacie SP1 slipstreaming guide. Oczywiście należy pamiętać, że MS miał jakiś powód (nie ważne czy merytoryczny) aby domyślnie zablokować integrację w trybie offline ale jest to jak dla mnie zawsze lepszy pomysł niż zewnętrzne programy typu 7lite. pzdr

Nie ma sensu - jak wcześniej pisałem w tym wątku konstrukcja archiwum wim powoduje, ze oszczędność w tym przypadku jest niewielka a w przypadku najuboższej edycji "starter" będzie najmniejsza. pzdr

To ja wymienię pradziadka wszystkich takich programów czyli QEmu ale też choćby Parallels Desktop czy najmłodszy ale bardzo obiecujący zestaw VMLite Workstation. Zresztą nawet jeżeli działamy w VirtualBox to ze strony VMLite warto sobie ściągnąć pakiet vboot - jest w nim oprogramowanie do tworzenia i konwersji obrazów wirtualnych (a także ich montowania) obsługujące wszystkie podstawowe formaty (vhd, vdi i vmdk a także wim). W ogóle vboot jest fajną inicjatywą - w teorii pozwala na odpalenie dowolnego systemu z pliku wirtualnego (w trzech wymienionych wcześniej formatach), zarówno windowsy jak i linuxy - napisałem w teorii bo mnie się nie udało jak na razie odpalić XP ale głosy na forum sugerują, że to działa, natomiast mogę potwierdzić, że z siódemką nie było żadnych problemów (edycja Prof). pzdr

Masz jakieś iso (czy płyty) z których wyciągnąłeś te 11 obrazów wim, użyj po prostu tej na której miałeś w install.wim obrazy 32 bitowe, jeżeli nadal masz problem z rozróżnieniem to jako podpowiedź powiem, że edycja "starter" występuje tylko w wersji 32 bit. pzdr

Każdą publicznie dostępną poprawkę można ściągnąć z katalogu windows update: link Choć w tym przypadku raczej przydałoby się znać numery poprawek, dodatkowo MS przy comiesięcznym cyklu poprawkowym wydaje obraz płyty zawierający wszystkie poprawki jakie się w tym cyklu pojawiły. Jest też programik Windows Updates Downloader ale listy dla siódemki nie są oficjalnie wspierane na stronie, program można znaleźć tutaj: link więc może być kłopot z polskimi listami, angielskie można znaleźć tutaj link, zawsze to jakaś podpowiedź co ew ściągnąć z katalogu. Dodatkowo na stronie: XP net przy każdej porcji aktualizacji (czyli z reguły co miesiąc) pojawia się spis tego co ms podał któremu towarzyszą stosowne linki. pzdr ps tak dla przykłady dvd z grudniowym zestawem dla polskich wersji systemów: http://www.microsoft.com/downloads/details.aspx?FamilyID=41e8319b-7bea-423b-8f9d-f7f3aef55c62&displayLang=pl i styczeń 2011: https://www.microsoft.com/downloads/details.aspx?FamilyID=c29b043e-e7fc-420f-a2b5-a2c4f3d72045&displayLang=pl

Ano po to Panie kolego żeby sprawdzić czy winpe z którego odpalił się setup w ogóle widzi płytkę, setup odpala się z pomocą ramdysku z pliku boot.wim i jego uruchomienie nie jest jednoznaczne z faktem istnienia dostępu do nośnika instalacyjnego. Również wszystkie pliki setupu istnieją wewnątrz tego winpe (jest to zdublowana zawartość katalogu sources - kilka plików i katalogów pełniących inną funkcję - np instalację z wds) w przypadku setupu visty wymagaa była obecność pliku boot.wim w katalogu sources - w przypadku siódemki można sobie zbudować zestaw bez tego wymogu (to tak na marginesie - może się przyda w dalszym "kurczeniu"). Niezależnie od tego co się znajduje w pliku wim sama płyta instalacyjna występuje w dwóch wersjach przeznaczonych dla rożnych architektur - tam gdzie oryginalnie w pliku wim znajdują się pliki edycji 64-bitowych również zawartość winpe oraz katalog sources zawierają pliki dla tej architektury (oraz dodatkowo płyta zawiera niedostępne dla wersji 32 bit pliki rozruchu z efi), analogicznie dla wersji 32 bit. Generalnie nie ma znaczenia dla procesu instalacji w jełkiej wersji był sam setup, setup 32 bitowy bez problemu zainstaluje system 64ibit i vice versa ale istnieją przynajmniej dwie przesłanki za tym aby w przypadku multizestawów używać "podstawy" 32bitowej, po pierwsze wszystkie pliki jak i sam boot.wim będą mniejsze po drugie - setup 32 bitowy odpalimy na komputerze z procesorem który nie wspiera rozkazów 64bit w przeciwieństwie do setupu 64 bity. Reasumując - w twoim przypadku kiedy szukamy kilkudziesięciu (może trochę więcej) megabajtów żeby się zmieścić na płycie podstawa 64 bitowwa byłaby marnotrawstwem miejsca. ps - nadal uważam, ze pod taki zestaw warto sobie strzelić pena - tym bardziej, ze można dorzucić później więcej narzędzi - (a jak ci się zachce dodać jeszcze serwerowe pliki do wim to temat powróci), łatwiej też się bawić w instalacje nienadzorowane, dodawanie sterownikow w locie czy nawet programów. pzdr

Jeżeli będziesz integrował sp z obrazem/obrazami to nie ma potrzeby integracji poprawek bo sp w tym przypadku jest niczym innym niż kompletem wszystkich poprawek które ukazały się do momentu kompilacji samego sp. Późniejsze poprawki natomiast na pewno będą szły dwutorowo czyli wersja bez sp i z sp będą miały osobną wersję więc ew. późniejsze poprawki warto integrować dopiero po zintegrowaniu sp. pzdr

Komunikat sugeruje, że setup nie widzi urządzenia na którym spodziewa się plików instalacyjnych, wdus w tym miejscu klawisze SHIFT + F10 - powinna odpalić konsola, w niej wklep sobie "notepad" - odpali notatnik i zobacz czy możesz wczytać jakiś plik z cd. Plik nie chce się nagrać bo mimo wszystko jest z duży na płytę dvd - choć minimalnie, na płytę wbrew temu co jest na niej napisane zmieści się ok 4,5 GB a nie 4,7, można próbować dalej czyścić, wyrzucić zbędny balast, pytanie też czy budujesz zestaw w oparciu o nośnik 32 czy 64 bit? pzdr

Żeby sprecyzować, na systemie na którym działa konstrukcja: @echo off echo at+cpin="1234">pin print /d:com4 pin>nul rasdial "Iplus" "plusgsm" "plusgsm" nie działa @echo off echo at+cpin="1234">com4: rasdial "Iplus" "plusgsm" "plusgsm" czy też obie nie działają? pzdr

Po pierwsze trzeba było eksportować do jednego pliku, nie ma potrzeby eksportu każdego obrazu do oddzielnego wima. Po drugie, przy eksporcie należy pamiętać o kompresji (najlepiej /compress maximum) Po trzecie - Capture i Append służą do przechwytywania wskazanego źródła do obrazu przy czym capture tworzy nowy plik wim a append dodaje do już istniejącego. Teraz pytanie co pakujesz? Jeżeli wyeksportowałeś wszystkie edycje do 11-tu plików wim to nic nie zdziałasz z pomocą capture/append - załóżmy, że wszystkie obrazy znajdują się w jakimś katalogu d:\obrazy to właśnie ten katalog zostanie wraz z zawartością spakowany do wima jeżeli podasz go jako źródło a nie zawartość poszczególnych wimów, jeżeli chcesz w ten sposób łapać to każdy obraz należy albo rozpakować przez "aplly" albo zamontować i złapać punkt montowania, nadal jednak uważam, że wygodniej będzie wyeksportować wszystkie obrazy do jednego pliku (albo prawidłowo wyeksportować pierwszy wim). Pamiętaj tylko przy tym o kompresji (i flagach SKU jeżeli jednak zdecydujesz się na łapanie źródeł). prawidłowy eksport obrazów będzie wyglądać tak: imagex /export źródło.wim 1 docelowy.wim "Starter" /compress maximum imagex /export źródło.wim 2 docelowy.wim "Home Basic 32bit" /compress maximum imagex /export źródło.wim 3 docelowy.wim "Home Premium 32bit" /compress maximum imagex /export źródło.wim 4 docelowy.wim "Professional 32bit" /compress maximum imagex /export źródło.wim 5 docelowy.wim "Ultimate 32bit" /compress maximum imagex /export źródło.wim 6 docelowy.wim "Enterprise 32bit" /compress maximum imagex /export źródło.wim 7 docelowy.wim "Home Basic 64bit" /compress maximum imagex /export źródło.wim 8 docelowy.wim "Home Premium 64bit" /compress maximum imagex /export źródło.wim 9 docelowy.wim "Professional 64bit" /compress maximum imagex /export źródło.wim 10 docelowy.wim "Ultimate 64bit" /compress maximum imagex /export źródło.wim 11 docelowy.wim "Enterprise 64bit" /compress maximum pzdr

Spróbuj jeszcze czy działa bezpośredni zapis: @echo off echo at+cpin="1234">com4: rasdial "Iplus" "plusgsm" "plusgsm" pzdr

Ok - tylko w postaci podanej w poście #5 ten fragment nie trafia do modemu, po prostu tworzy się plik tekstowy o nazwie "pin" w ścieżce z której wykonywany był skrypt/bat i dalej nic się z nim nie dzieje. W skrypcie z postu #1 przynajmniej był wysyłany/drukowany do portu com4 czyli jak rozumiem portu reprezentującego modem. pzdr

Tak gwoli ścisłości, nie wydaje się wam, że linijka: echo at+cpin="1234">pin nie jest do niczego używana, tworzy co prawda plik o nazwie "pin" ale czy coś się z tym plikiem dalej dzieje? Jeżeli tak to można zastosować sam vbs typu: Dim oShell Set oShell = WScript.CreateObject ("WSCript.shell") oShell.run "rasdial Iplus plusgsm plusgsm",0 Set oShell = Nothing nawet jeżeli nie to nadal można uprościć do pojedynczego skryptu bądź tworząc tymczasowy bat bądź stosując taką konstrukcję: oShell.run "%comspec% /c echo at+cpin=1234>pin | rasdial Iplus plusgsm plusgsm",0 jak widzicie wywaliłem wewnętrzne cudzysłowy bo wysypią skrypt, trzeba by je zastąpić znakami chr(34) a to bardzo gmatwa składnię a same cudzysłowy są tutaj zbędne (jak i echo off bo i tak nie wyświetlamy wyjścia). Jeszcze słowo wyjasnienia o konstrukcji: oShell.run "cmd /C .\C:\Users\Mathew\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\iplus.bat",0 spacja we fragmencie "Start Menu" powoduje, że ta konstrukcja nie zadziała, na dodatek strasznie trudno się to obchodzi w skryptach, proponowana przez @3oo %appdata% też niewiele da bo zostanie rozwinięta przez komendę, na dodatek można ustawić wewnętrzną zmienną typu "SpecialFolders" link Spacje w ścieżkach prowadzą do następujących konstrukcji - fragment jednego z moich skryptów: objShell.run "%comspec% /c" & chr(34)& strprogramfiles &"\InstallShield Installation Information\{7F3AD00A-1819-4B15-BB7D-08B3586336D7}\setup.exe"&chr(34) &" "& "/runfromtemp /l0x0009 /uninst",0,true pzdr

proszę spróbować imagexa z pakietu WAIK w najnowszej wersji, można też spróbować obejścia polegającego na rozpakowaniu i ponownym złapaniu poszczególnych obrazów (praco i czasochłonne). pzdr

AD 1 - nie do końca, mechanizm side by side wbudowany w Windows dąży do zachowania wszystkich możliwych wersji choćby bibliotek czy też plików współdzielonych. Ale podejrzewam jeszcze coś, czy po takiej integracji wyczyściłeś wim? Przyrost o 1,2 GB to trochę za dużo, po integracji SP1 (a ten jak wiemy zawiera komplet poprawek) wim 64 bitowy rośnie o około 0,5 GB a biorąc pod uwagę to co napiszę/napisałem poniżej pełny zestaw nie powinien wiele przytyć. Jakiekolwiek operacje w plikach wim nie usuwają z niego plików, pliki zastępowane/kasowane tracą przypisanie do konkretnego obrazu/indeksu ale pozostają wewnątrz wim-a, wystarczy wczytać wim za pomocą 7zip i zobaczyć czy oprócz poszczególnych obrazów 1,2,3...n widnieje jeszcze w głównym drzewie katalog "files" - to są właśnie śmieci. Na tą chwile jedyną metodą pozbycia się tego ustrojstwa jest eksport wszystkich obrazów po kolei do nowego pliku wim. AD 2 - jeżeli plik nadal będzie przyduży należałoby się zastanowić na rozbiciem na dwie standardowe wersje - 32 i 64 bit i zbudowanie jednak oddzielnych nośników - kasowanie pojedynczego obrazu niewiele da, plik wim jest archiwum różnicowym, każdy plik który powtarza się w różnych indeksach w samym archiwum występuje tylko raz, jest przypisywany tylko do poszczególnych obrazów w, ponieważ między edycjami windows w ramach tej same "bitowości" występują niewielkie różnice w plikach to i rozmiar niewiele się zmienia (kiedyś sprawdziłem, między samotną edycją HP 32 bit a pełnym zestawem pięciu wersji różnica w rozmiarze to około 6%), można też wypróbować płytę dwuwarstwową a najlepiej zbudować sobie taki zestaw na penie (oczywiście w tym przypadku sformatowanym w NTFS). pzdr

Zgadza się, ale to nie problem, Erunt mimo komunikatu wykonuje prawidłową kopię tego pliku (jak też przywracanie). Swoją drogą autor dawno obiecał poprawkę i jakoś zwleka pzdr

Używam dość regularnie na 64 bitowej siódemce i nie zgłaszają problemów, pojawia się komunikat tylko jeśli partycja z konfiguracją rozruchową (chodzi o BCD) jest niedostępna w systemie (brak przypisania, id OEM itp) ale nie wpływa on na samo działanie programu. Napewno odpalasz z uprawnieniami administracyjnymi? pzdr

Akurat pliki instalacyjne systemów niewiele pomogą w tym przypadku, sam setup też rozumiem jest po Polsku więc zakładamy, że WinPE ukryte w pliku boot.wim też występuje w wersji w pełni spolszczonej. W takim wypadku są dwie opcje które wymuszają taki a nie inny język startowy dla setupu, po pierwsze należy sprawdzić czy w katalogu boot są dostępne właściwe lokalizacje (czylli podkatalog pl-PL) po drugie w BCD dla odpowiedniej sekcji startowej powinna być ustawiona odpowiednia lokalizacja: bcdedit /set {default} locale PL-pl oczywiście należy operację wykonać na kontenerze płyty instalacyjnej więc raczej bcdedit /store "odpowiednia ścieżka" Na siłę można też ustawić lokalizację dla wpisu nadrzędnego: bcdedit /set {bootmgr} locale PL-pl pzdr