Windows deployment mivel?

Microsoft Windows

Sziasztok,

egy oktatási intézményben szeretnénk adott esetben leváltani a már működő, de saját készítésű Windows deployment megoldást (Linux bootol, particional -> Win PE -> Win install). A céljaink között szerepel többek között az is, hogy Linux is legyen a gépeken, valamint hogy mind a Windowst, mind a Linuxot Puppettel menedzseljük. A megvalósításhoz szeretnénk elkerülni egy Windows Server telepítését, rendelkezésre fog állni viszont egy Samba 4 szerver. Ami fontos, hogy a jelenlegi Windows XP-s megoldást szeretnénk upgradelni Win 7-re.

Kérdésem: Milyen elterjedtebb technológiákat ismertek, amik segíthetnének mérsékelni a házibarkács munka mennyiségét?

Köszönöm

  • 15753 megtekintés

( SzBlackY | 2014. 02. 23., v – 10:18 )

Subscribe

Hány féle gép van? Imagelés (pl. Clonezilla server) nem játszik úgy, hogy Linuxból/Win-ből is felhúztok egy-egy syspreppelt/ /.unconfigured-ölt (<- de hülyén néz ki :D ) image-t, onnantól a konfigolást elvégzi a puppet?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Csináltuk. Win2k-val. Az ellenségemnek se kívánom (vissza) azt...
A gépek sokfélesége nem menedzselhető (ergó sokféle van), igaz, sokat fejlődött a Win a 2k óta devicedriverszopásilag, de a boot diszk driverének cseréje szerintem továbbra sem fér bele az image-elésbe. Márpedig nem óhajtunk n-féle verziót gyártani ettől függően, továbbá nem szeretnénk az ahci-s gépeket ide-compatible módban használni.

A Windows telepítő Vista óta WIM image alapú. Ahogy abba úgy egy saját WIM image-be is beintegrálhatod a megfeleleő (sata, net, stb.) drivereket. Így a saját syspreppelt image az első induláskor tudja majd használni a megfelelő drivert.

További infók:
http://technet.microsoft.com/en-us/library/hh825070.aspx
http://www.commodore.ca/windows/inject_drivers_pe_3_0_windows_7/inject_…
http://www.deploymentninja.com/3/post/2012/07/easily-add-drivers-and-up…
--
Légy derűs, tégy mindent örömmel!

De itt, ebben a szálban image másolásról beszélgettünk eddig... tehát NEM telepítőt indítunk, hanem az image-et átmásoljuk egy már telepített gép HDD-jéről egy másik gép HDD-jére. Az a mondás szerintem továbbra is áll, hogy ha az új gép más drivert igényel a boot diszkjéhez, akkor egy ilyen másolás után be se fog bootolni.

1. A referencia gépen image készítés előtt sysprep futtatása.
2. WinPE boot és WIM image készítés imagex programmal.
3. Ha kell driver, es/vagy frissítések importálása az elkészült referencia image-be.
4. Image visszatöltés az új gépre.
5. Új gépen az első bootnál induló mini telepítő használja az utólag betett drivert.

Annyi még hogy mivel egy Windows Vista/7 stb. esetén max 3 aktíválás/sysprep ciklus engedélyezett ezért célszerű a referencia gépet virtuális gépen elkészíteni (pl. VirtualBoxban), mivel drivert lehet importálni az image-be ez nem gond(, bár néhány VM beállításra pl. ACPI figyelni kell). Így ha sysprep előtt egy snapshoot készül, onnan később lehet folytatni ha módosítani kell a reeferencia image-t.
http://emeneye.wordpress.com/2012/04/18/adding-drivers-to-a-windows-7-i…
--
Légy derűs, tégy mindent örömmel!

( gergov | 2014. 02. 23., v – 10:18 )

*feliratkozás
(Csak mert nekem a RIS + unattended xml + házi .wim fájl extended attributes támogatás hiányában nem jött be.)

( aspirin v | 2014. 02. 23., v – 10:45 )

(érdekelhet :))
<-------
You can't grep on dead trees.

( uid_4656 v | 2014. 02. 23., v – 16:02 )

Ez engem is érdekelne, akár úgy is, hogy kell hozzá Windows szerver is.

Windows Serverrel együtt a legegyszerűbb - és supportált - megoldás fogni a Microsoft Deployment Toolkit-et (Win server nélkül AFAIK csak a light touch vagy ilyesmi deployment megy, a zero touch deploymenthez kell neki néhány WinSrv komponens és talán egy MS SQL db).

Szerk.: Na, utána olvastam. Elvileg a Lite Touch-al is megoldható a network install (itten), a Zero Touch-hoz kell egy Configuration Manager 2007 R2 vagy afölötti szerver. (Az MFT-t annó egy olyan Win7 telepítő létrehozására használtam, ami DVD-ről bootolt és feldobált minden szükséges progit, a netes telepítéssel nem játszottam)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Fáj a fejem és pontatlan voltam. Windowst IS akarok deployolni linux mellett. Olyasmikkel van gondom, hogy a PXE kérésre éppen a WDS vagy a linuxos PXE szerver válaszol. Ha meg megkerülöm és külön VLAN-ba teszem a windows és a linux deployment szervert, akkor switchet kell konfigolnom ahhoz, hogy deployoljak. Ilyenek. Szóval csak olvasni akarom a threadet :-)

A fenti hozzászólás után utánanéztem, hogy az MDT-s telepítő image mennyire bootolható, netes írások alapján a PXELINUX memdisk-ként el tudja indítani, így viszonylag jól scriptelhetővé tehető:
* pxelinux.cfg/default - chain a local lemezre
* pxelinux.cfg/wininstall - memdisk a PE image-re
* pxelinux.cfg/linuxinstall - disztrófüggő installer kernel

Utána symlink + WOL párossal egész kényelmesen használható lehet*, persze csak akkor, ha nem ütközik pl. a partíciónálás beállítás a Win és Linux installereknél.

*: még valahogy a symlinkek kiírtását kell megoldani, Süsüs Yast ezt alapból tudja, MDT-nél valszeg scriptelhető

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Kösz a tippet, majd utána olvasok, egyelőre még a fentit akarom megcsinálni (csak nekem tűnt fel, hogy ma a microsoft oldalak rohadt lassúak voltak ill. kaptam párszor server error-t? Egy élmény volt így telepíteni a Windows Assessment and Deployment Kit-et [a WAIK legújabb neve :) ]).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( csontika v | 2014. 02. 23., v – 16:30 )

1. http://www.ultimatedeployment.org/win7pxelinux1.html
2. acronis ha fizetőset és profit szeretnél 0 barkács:)
3. win szerver WDS (kb egy óra alatt működőképes win telepítéssel)
domain kell, de az amúgy is ajánlott ilyen környezetben mac címre tudod szabni melyik gének milyen drivert tegyen fel a csomagba, tisztaszoftveres dvd-ket benyeli, és az összes win werziót telepítheted ami jól esik, stb. ehhez képest minden linuxos megoldás barkács lesz.

ilyen helyre megfontolandó a vékonykliens megoldás:
20 embör megfér winserver 2003 3Gramon, 2008 nál se hiszem rosszabb lenne a helyzet

pár ötlet a végére:
http://www.howtogeek.com/166205/how-to-easily-reset-a-computer-back-to-…
http://answers.microsoft.com/en-us/windows/forum/windows_7-security/cre…

Amúgy ameddig biztosítják a suliknak a wint miért nem azt használtok (ettől lehet mellé dual boot stb.)? Ha meg már nem biztosítják úgyse win lesz:)

Amúgy ameddig biztosítják a suliknak a wint miért nem azt használtok

pl. mert akkor a következő márciusban, amikor a kormány meglebegteti a tisztaszoftver dobását és újra felmerül ez a kérdés, azonnal jön a "hát persze mert nem gondolkodtatok előre, ígyjárás"-típusú kommentek áradata? :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Épp most sz*punk ezzel Romániában. A kormány meggondolta magát, Win7+8+O2010/13 és a Server 2012R2 megy a levesbe.

Péntekig le kell tolni mindent, próbálgatom is bőszen a puppet-et, mert elegem van a sok telepítgetésből.

Itt XP, Vista lesz, mellette valószínű hogy egy Ubuntu azokon ahol jól megy.

Idézet:
Amúgy ameddig biztosítják a suliknak a wint miért nem azt használtok

pl. mert akkor a következő márciusban, amikor a kormány meglebegteti a tisztaszoftver dobását és újra felmerül ez a kérdés, azonnal jön a "hát persze mert nem gondolkodtatok előre, ígyjárás"-típusú kommentek áradata? :)

Konkrétan a tisztaszoftveres XP idén januártól "this is not a genuine windows" szöveggel üdvözöl... Decemberben még jó volt. Gondolom "lejárt" a licensz...

licenceket évente igényelni kell, különben tényleg lejár

minden márciusban szó van róla, aztán visszatáncolnak, jól olajozott a gépezet sajnos

így járás már rég fennáll, mert ilyen jellegű áttéréseket szerintem nyárra kell ütemezni ekkor a betanulás már nyáron megkezdődhet és kisebb lesz a hercehurca.
esetleges új oprendszerhez hozzáigazítani a tanmenetet évközben bajos.
Tehát tanév közben váltani szerintem minden szempontból rossz ötlet.

És ha nem lesz tisztasz. program, akkor mindenki sütheti a windows-át, mert megy a downgrade win7 basic... vagy amivel vette (se domain, se winszerver)
ekkor megint nincs értelme szívni win lin automatikus pxebootos cifraságoknak, mert marad a lin+win ahova kell clonezillával;)

Azért most már nem akkora szopás, legkésőbb nyáron jön ki a RHEL7 (így a CentOS 7 is) gyárilag Samba 4.1-el, úgyhogy a domain többé-kevébé megoldva, a menedzsment-eszközöket kell függetleníteni.

Ami az igazi szívás, az az Office csomag, annál ugye bukják az MSO-t (cserébe ott az LO/OO) és az azért túlságosan tananyag. Viszont ott már tényleg eseti döntésnek kellene, hogy legyen, a gép és licenszpark ismeretében lehet jó döntést hozni; az viszont valszeg nem lesz, mert központosították az iskolákat.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ami az igazi szívás, az az Office csomag, annál ugye bukják az MSO-t (cserébe ott az LO/OO) és az azért túlságosan tananyag.

Hát, nem sokáig lesz az. Ugyanis az igazi szívás az, hogy jövőre kikerül a 2003-es és a 2007-es Office a hivatalos érettségis szoftverlistából. A 2010-es sose került fel rá, ergó MS Office-ból csak a 2013-as lesz a listán. Amit max. elrettentő példának lehetne mutogatni a tananyag keretében.

A Samba4-től azért én nem várnám azt, hogy hirtelen ki tudja váltani az AD-t. Nemrég csináltam egy projektet, amelynek része volt az, hogy csináljak egy domaint Samba4 alapokon - hát, igen erősen vágytam arra, hogy kapjak egy Windows Servert helyette. A tapasztalatok alapján mindent meg lehet csinálni Samba4-gyel, amit meg lehet csinálni egy AD-vel és a gyakorlatban kérik is, de bizonyos részek (pl. a GPO-k kapcsán) meglehetősen pilótavizsgásak. Nem hiszek benne, hogy az összes iskolai rendszergazda úgy hirtelen kisujjból kirázná a dolgokat, a megfelelő minőségű/mennyiségű howto-hoz meg kell még legalább 2-3 év.

Mi a gond a GPO-kkal? (leszámítva az NTFS jogosultságokat, amikre a kliensek ugranak és az automatikus DC-k közti szinkronizálás hiányát, ami rsync-cel megoldható ill. [bár még nem teszteltem] a gluster vfs driverrel [ami nagy jóság lehet, storage cluster közvetlenül SMB-n kiajánlva] tippre kényelmesen megoldható lesz előbb-utóbb)

Szerk.: Ill. a RHEL7-et azért írtam, mert ők elég rendesen dokumentálni szokták a cuccaikat, szerintem előbb-utóbb frissíteni fogják a 7-es doksijait (most még nagyon úgy tűnik a hármasról van benne szó), akkor már dokumentáció is lesz hozzá.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Csomagtól függően gond nélkül működik out-of-the-box, ha pedig az üzemeltető a domain provision után kapcsolná be az xattr-t a fájlrendszeren (dokumentációt olvasni kéne, ugyebár), akkor egy samba-tool ntacl sysvolreset megoldja. Jahogycsakennyi.

Sőt, a vfs_gluster nélkül is megoldható a gluster backend a sysvol-hoz, csak akkor fel kell csatolni (vagyis átmegy a kernelen, a fuse-on és a glusterfs fuse implementációján) és figyelni kell arra, hogy mindenkinek, akihez ACL kötődik a sysvol-on, legyen uid-je/gid-je az AD-ben. Háturisten, lol.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hanem? Két dolgot írtam, amire jöttél az egyszavas kommentjeiddel:

* az ACL-ekkel gond lehet, ha nincs alatta olyan FS, amin a samba tárolni tudná őket. Közben kipróbáltam, a Win2k3 valóban picsog a Sysvol miatt, ha FAT-ra akarnád tenni és nem engedi a dcpromo-t - másik oldalról meg: nincs olyan időpont, ahol a Samba ellenőrizni tudná, hogy alkalmas fájlrendszeren van-e és le tudna állni, mert a Winnel ellentétben 1) áthelyezhető a sysvol share és 2) szabadon módosíthatók az elérési utak
* nincs Sysvol replikáció - a sambába építve. A hivatalos álláspontjuk az, hogy vannak rá jobb eszközök (rsync, osztott storage ...), úgyhogy low priority cucc (ráadásul itt is kapásból két MS megoldást a DFS-t és az FRS-t kéne implementálniuk a teljességhez), ha lesz rá idejük majd lesz out-of-the-box replikáció. Erre írtam példaként a vfs_gluster-t, ami eléggé Red Hat-közeli és Samba-only környezetben szépen működhet, ha beérik, nem tudom, hogy a RHEL7-re bele merik-e majd tenni.

És akkor a te értelmezésed:
* mekkora szar a samba, hogy az elméletileg sem megoldható problémát (garantálja, hogy acl/xattr-képes FS legyen a sysvol alatt) megoldja*/** és hogy nem implementál két MS-only átviteli megoldást, amire az ajánlott, csak Samba-s környezetben nincs is szükség, hanem inkább bugfixel.

*: továbbra is, cserébe ad EGY darab utasítást, amivel default-ra állítható a teljes sysvol share, amint van alatta normális FS.
**: az egész a RHEL7-től indult, ahol amúgy az XFS lesz a default fájlrendszer, amin alapból van acl/user_xattr/quota.

BlackY
Szerk.: Off-topic: viszont a Win2k3 server kérdés nélkül berakná az NTDS-t a FAT32-n ülő Windows mappába... hupsz.
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem-nem, egy rakas feltetelezessel eltel. A te hulyesegeid meg ne tedd a szamba. Elhiszem, hogy miutan mar kivulrol fujod az egeszet, nagyon prima neked, de kozvetlenul ebben a szalban is tobben jeleztek, hogy nem eszik olyan forron a kasat, mint ahogy te habzo szajjal eloadod mindenkinek, aki barmifele ketseget jelezni mereszeli.

"nincs olyan időpont, ahol a Samba ellenőrizni tudná, hogy alkalmas fájlrendszeren van-e és le tudna állni"

De, van. Az egyik a provisioning - ekkor egyebkent ellenorzi is -, a masik pont pedig a sysvol athelyezesenek pillanata. Es van egy harmadik is - indulaskor is ellenorizni kellene, hogy jol van-e felmountolva a sysvol-t tartalmazo mountpoint. Mind elmeletileg, mind pedig gyakorlatilag megoldhato problema.

Egyebkent: senkit nem erdekel, hogy honnan indult az egesz. Ha ez egy RHEL7-only cucc lenne, akkor valid lenne az az erv, hogy szamit, mi az RHEL7 default fs-e, de igy abszolut erdektelen a felvetes.

A replikaciora amugy ugyanez vonatkozik: az ajanlott konfiguracio altalaban egy idealis helyzetet vazol fel, es nagyon ritka, hogy osszejon. Nem ugy kellene szoftvert fejleszteni, hogy van az ajanlott konfiguracio, a tobbiek meg lojek magukat a Dunaba/Volgaba/barmimasba.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Az egyik a provisioning - ekkor egyebkent ellenorzi is -,

Meg kellene néznem a changelogot, hogy mikortól, régebben futottam ebbe bele.

a masik pont pedig a sysvol athelyezesenek pillanata.

Erről honnan tud a Samba?

Es van egy harmadik is - indulaskor is ellenorizni kellene

És semmire nem mennének vele. A share-ket tartalmazó mappáknak nem kell léteznie a Samba indulásakor, az első csatlakozáskor próbálja elérni őket (és dob vissza hibát a kliensnek, ha nem sikerül); a Sysvol pedig egy sima share, és szvsz. egy 6 karakteres sima string azonosító alapján nem kellene külön code pathekbe rohangáltatni a rendszert. De még ha ellenőrizné is: (az öntökönlövés iskolapéldája, de megtehetem), csinálok egy symlinket egy jó fs-en levő mappára /srv/smb néven, létrehozok rajta egy sysvolt könyvtárat, elindítom a Sambát, szépen ellenőrzi, stimmel a /srv/smb/sysvolt, utána egy laza mozdulattal áthúzom a /srv/smb-t egy rossz fs-re, ahol szintén van sysvol mappa.

Igen, bezethetnének egy "a legtöbb esetben megvédjük az admint magától" megoldást egy csomó új code path-el, sok értelme nem lenne. Ráadásul ezt éppen nem cseszte el annyira az MS, ha bármi nem teszik neki a Sysvol ACL-ek környékén, azonnal logol egyet, kiszáll és nem folytatja a feldolgozást, úgyhogy a biztonság sem sérül.

senkit nem erdekel, hogy honnan indult az egesz.

Idézem magam:

Azért most már nem akkora szopás, legkésőbb nyáron jön ki a RHEL7 (így a CentOS 7 is) gyárilag Samba 4.1-el, úgyhogy a domain többé-kevébé megoldva

Nem ugy kellene szoftvert fejleszteni, hogy van az ajanlott konfiguracio, a tobbiek meg lojek magukat a Dunaba/Volgaba/barmimasba.

Nem is úgy fejlesztenek, hanem közlik, hogy nincs replikáció, ha lesz idejük megoldják. Ráadásul itt aki lépni akar mondjuk egy W2k3-ról (2015 áprilisban jár le a support, ugyebár), annak érdeke is lehet az ajánlott konfiguráció előállítása, mert onnantól kezdve nem kell neki CAL a gépek/userek után.

Szerk.: Ill. ha ellenőrizné, nem lenne Windows kompatibilis. Kipróbáltam, hogy kihúztam az NTFS-t az AD alól és a SYSVOL-t átmásoltam egy FAT32-re, felcsatolva az NTFS helyére a hálózaton elérhetővé teszi.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Kezdjuk az elejen:
- a sysvol - mint jo nehany egyeb share is a sambaban - specialis share, igy akar erdemes is lehet ellenoriztetni az alapjan a 6 karakter alapjan, ugyanis mas share-t nem tudsz kinevezni sysvol share-nek, csak azt, aminek az a neve, hogy sysvol. Azt kellene megerteni, hogy a Samba halozatban mar eleve van egy csomo megosztas, aminek specialis jelentese es mukodese van, es egy fix neven hivatkozunk ra. A sysvol, a printers, a homes megosztasok nem attol specialisak, hogy mi van bennuk, vagy milyen a konfigjuk, hanem pusztan a nevuk alapjan dont el a Samba egy csomo mindent roluk. Az alapjan mar van egy csomo meglevo codepath, szoval emiatt kar aggodnod vagy izgulnod.
- "utána egy laza mozdulattal áthúzom a /srv/smb-t egy rossz fs-re, ahol szintén van sysvol mappa" Erre megoldas az, hogy feloldjuk a realpath-et, es onnantol arra hivatkozunk. Ugyanis egy share eseteben nem kovetelmeny, hogy az menet kozben kovesse le a symlink valtozasokat. A mount ellenorzesehez egyebkent amugy is fel kell oldani a realpathet, szoval ez nem jelenetene kulon code pathet.
- "felcsatolva az NTFS helyére a hálózaton elérhetővé teszi." - persze, mert ez reszben egy ugyanolyan szerencsetlen share mint a tobbi. De nagy a valoszinusege annak, hogy maga a sysvol megosztas (nem mint megosztas, hanem mint sysvol megosztas) erosen mukodesi problemakkal kuzd a tesztrendszereden, ugyanis ez meg Windows alatt sem recommended scenario. Attol, mert egy alapvetoen nem mukodo scenariot sikerult mukodesre birni, meg nem lesz inkompatibilis semmi semmivel. Ez csak arra utal, hogy a Microsoft nem keszult fel arra, hogy valaki az AD-be ennyire non-recommended modon belenyul, mert ez arrafele nem szokas.

Komolyan, nem akarok veled vitatkozni, mindossze annyi van, hogy en eleg sok samba halozatot raktam mar ossze, van neminemu fogalmam arrol, hogy hogyan mukodik a Samba ott belul.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A mount ellenorzesehez egyebkent amugy is fel kell oldani a realpathet, szoval ez nem jelenetene kulon code pathet.

Egy grep -r sysvol * a samba 4.1.5 forrásában másról tanúskodik. Elágazásban egy helyen szerepel, dfs_server/dfs_server.c 


       /*
         * Here we have filtered the thing the requested name don't contain our DNS name.
         * So if the share == NULL or if share in ("sysvol", "netlogon")
         * then we proceed. In the first case it will be a dc refereal in the second it will
         * be just a sysvol/netlogon referral.
         */
        if (strcasecmp(dfs_name, "sysvol") == 0 ||
            strcasecmp(dfs_name, "netlogon") == 0) {
                return dosysvol_referral(lp_ctx, sam_ctx, client, r,
                                         server_name, dfs_name);
        }

Ezen kívül Python szinten jelennek meg eltérő code path-ek, de ránézésre nagy része az upgradeprovision környékén, ill. persze a sysvolcheck/sysvolreset-nél.

hogy a Microsoft nem keszult fel arra, hogy valaki az AD-be ennyire non-recommended modon belenyul, mert ez arrafele nem szokas.

Viszont ugyanez elvárás a Samba-tól, gondolom mert errefelé szokás?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Semmi gond a GPO-kkal. De ahogy Te kapásból írtál 2-3 dolgot úgy még van 3-4 másik dolog is, amit reszelnem kellett - kétségtelen, hogy minden összereszelhető volt, de biztos vagyok benne, hogy sokkal több reszelést igényelt, mint fellőni két Windowsos DC-t.

A kulcsot Te is írod - "előbb-utóbb" jó lesz ez, de most még nem az.

Illetve erosen verzioszam-erzekeny a dolog. Annyira dinamikusan fejlodik a Samba 4, hogy igazabol a forrasalapu disztrokon kivul egyik sem tudja lekovetni, es verzionkent kettonna bugot javitanak ki benne. En epp most csomagolok egy 4.1.3-as Samba-t ubuntura, mert csomagban sehol nincsen, az Ubuntuban levo verzio meg olyan bugos, mint egy termeszvar. Es mire vegzek, kezdhetem elolrol a munkat a 4.1.5-oshoz.

Ja, es egy tobb DC-s kornyezetnel minden Samba4-nek bitre pontosan meg kell egyeznie, kulonben a replikacio... hat... "erdekesen" mukodik.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

- Regisztraciokoteles, de ennel nagyobb problema, hogy regisztracio nelkul _semmilyen_ informacio nem erheto el a lehetosegekrol. Falsra meg nem regisztralok sehova.
- Utanaolvasgattam tobb oldalrol is a Samba 4-nek, mielott nekialltam portolni, ugy remlik errol irtak azt, hogy abszolut nem kompatibilis az Ubuntu samba4 csomagjaval, nem csereli le azt, hanem valami total custom megoldas. Azt pedig nem szeressuk.

Egyebkent kosz az infot, de mar keson jott.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Elég, bár van egy pár finomság az enterprise-ban és valószínű hogy időt is lehet spórolni vele.

XP-n és Vistán fut a 3.x-es agent, bár nem szerepelnek már a támogatott platformok közt. Remélem a magasabbröptű funckciók is mennek (telepítés, registry, local gpo pl.) és nem rontottak el semmit szándékosan.

Ami fura volt... 3.x-es szervert és 2.7-es agent-et nem sikerült összeboronálni: nem jelent meg az agent certificate-je a szerveren.

Puppetnel egy fontos szabaly van: minden agentnek ugyanolyan verziosnak _kell_ lennie, mint a masternek. Foleg a 2.7-3.x hozott egy baromi nagy valtast (linuxon ossze is panaszkodja magat, hogy nem kompatibilisek), de meg ket eltero 2.7.x-essel se orom az elet.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( mr shadow v | 2014. 02. 23., v – 20:50 )

sub
--
>'The time has come,' the Walrus said<

( kila | 2014. 02. 23., v – 22:07 )

Esetleg célszerű lehet VHD image-be telepíteni az operációs rendszereket, ami Windows és Linux esetén is lehetővé teszi, hogy Virtuális gép snapshot/appliance megközelítéssel lehessen több Operációs renszert/VHD fájlt használni egy gépen.
http://technet.microsoft.com/en-us/windows/dd758779.aspx
http://jaminquimby.com/joomla253/work-stations/85-windows-7/73-how-to-i…
http://www.vmlite.com/index.php?option=com_content&view=article&id=51&I…
http://www.vmlite.com/appliances/ubuntu-1104-readme.html
http://vmlite.org/index.php?option=com_kunena&Itemid=158&func=view&cati…
--
Légy derűs, tégy mindent öröemmel!

VHD-ről (vagy wim-ről?) a Win7-es boot loader tud "natívan" is bootolni, a "mire használható a Bittorrent sync" oldalon volt egy arc, aki írta, hogy azzal terjeszti a gépeken az image-ket. (persze az alap rendszer terjesztésre továbbra is gond)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nincs részletesen leírva, de ha itt http://forum.bittorrent.com/topic/18320-the-types-of-things-people-are-… rákeresel a moonboon névre, ott lesz.

Gondolom a megvalósítás valami olyasmi, hogy a kliens gépeken permanent read-only elérés van, és valamivel figyeli a mappa változásait, aztán szerkesztgeti a BCD-t.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Csak a diszk "virtualizált" mivel a VHD fájlt használja rendszer diszkként az OS, ez kb. 1-2% overheadet jelent. Amúgy boot manager és VHD-t kezelő driver kérdése az egész, amit a Win 7 alapban tud. Linux-nál pl. a vboot és a megfelelően elkészített initrd image kell.
Az alábbi linken lévő hozzászólásokban WinXP esetére is van VHD boot leírás.
http://reboot.pro/topic/15516-create-native-boot-vhds/
http://reboot.pro/topic/15815-boot-win-7-vhd-on-bare-metal-pc-from-empt…
--
Légy derűs, tégy mindent örömmel!

Iskolai laborról van szó, ahol így egy HDD-n belüli VHD másolással vagy differencial VHD használatával snapshoot szerűen gyorsan vissza lehet állni egy vagy több alapállapotra a gépeken.
http://reboot.pro/topic/16598-vhd-differencing-disks-and-native-vhd-boo…

szerkesztve:
Windows 7 "SteadyState" megoldás VHD boot és differencial VHD használatával.
http://blogs.technet.com/b/panosm/archive/2011/07/07/windows-7-steadyst…
--
Légy derűs, tégy mindent örömmel!

( SzBlackY | 2014. 02. 25., k – 18:45 )

Nyah, folytatva a kísérletet: miután tegnap nagynehezen letöltöttem a WADK 8-at (WAIK új neve), a Deployment Workbench közölte, hogy neki a 8.1 kell. Úgyhogy újraletöltés, ma már valamivel gyorsabban válaszoltak az MS szerverek.

Ami működik: PXE-vel behúzok egy iPXE-t, ami egy PXELINUX-ot, az már el tudja indítani a WADK által generált PE image-t simán iso fájlból. Az iso fájlba a bootstrap.ini-be fel lehet vinni egy domain user-t a deployment share elérési útja mellé (a PE UI-n megadva működött a hosszú felhasználóneven@tartománynév, a konfig fájlból valamiért nem akarta az igazat, végülis visszaírtam a rövidet és újrageneráltam nulláról az iso-t, a kettő közül valamelyik működött), így a telepítés onnan megy (UI-n megadva nem jegyzi fel magának a credentials-okat, úgyhogy a telepített rendszerre belépve már nem éri el a sharet). Windows 7 szépen települ, ha a varázslóban beadom neki a domain nevet / számítógépnevet azt szépen beállítja és belép a domain-be (probléma: ha jól rémlik a CustomSettings.ini-ben meg lehet adni a gépnevet, valahogy azt kell megoldani, hogy a megfelelő gép a megfelelő CustomSettings.ini-t kapja meg), a workbenchen bepakolt alkalmazásokat telepíti (Firefox ESR-el tesztelve).

A management gépen ehhez kellett a WADK (-> .NET 4.5), a Microsoft Deployment Toolkit és - ha már úgyis van ez a gép :) - az RSAT, szerveren Samba 4 (sernet 4.1.5 build Debian-on), tftp és www szerver (<- image-t arról töltöm, egyrészt gyorsabb, másrészt nem volt kedvem debugolni, hogy tftp-n miért hal le blksize hibával az átvitel).

Szerk.: Amit még meg kell oldani (bár valahogy ezt annó sikerült kiszednem, de nem találom hol), hogy a PE CD image kér egy billentyűleütést, ha van aktív partíció.
Szerk II.: a CustomSettings-ben egy Priority=Default,MACAddress és utána [MA:CC:ím] szakaszokban levő OSDComputerName ezt is megoldja, egyszer le kell generálni ezt a listát.

--

Frissítés: az MDT szépen felnyalja a Windows Update Downloader által letöltött MSU fájlokat, deploy közben viszont - ha engedélyezve van a mappa - elhasal az "Applying unattend.xml with DISM" című résznél. Holnap próbálok keríteni integrált SP1-es telepítőt, aztán meglátjuk.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Tegnapi további próbálkozások eredménye: nem sikerült SP1-es telepítőt akasztanom (integrálni lehetne, de az nem ugyanaz :) ), viszont -- VirtualBox-on belül maradva -- gond nélkül túléli egy image-lés a PIX3->ICH7, egy mag->négy mag, 1G RAM->2G RAM [ez mondjuk annyira nem nagy szám], Intel HDA -> AC'97, SATA -> LSI SAS váltást, települ bootol. Vagyis akár használható úgy is, hogy egy gépen összes WinUpdate fel, image, utána azt az image-t terjesztve (az image-léshez kellenek az eredeti telepítőfájlok az OS importálásakor, kivéve, ha már van olyan OS, így célszerű a teljes folyamatot MDT-ből intézni)

Kényelmesen használható és működik az appok telepítése, akár utólag is, fel kell csatolni a deployment share-t, aztán a gyökeréből indítani a scripts\bdd_autorun.wsf fájlt, a kelleténél hárommal több kérdéses varázslót ad alapból, egy erre kihegyezett CustomSettings.ini-vel megoldható (ad absurdum: linkekkel csinálni lehet egy telepítős deployment share-t, ahol a CustomSettings.ini-ben csak a varázsló lapokat letiltó konfigok vannak, így akár az end-user is tud válogatni az appok közül. Cserébe a verzióváltás erősen telepítőfüggő, azt tesztelni kell.)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Tisztaszoftverest kicsit nehezebb :( és csak a jó ég tudja, hogy mit taknyoltak állítottak benne az unattend.xml-ből indított kms beállításon kívül. (mondjuk közben rájöttem, hogy amelyik gépen OEM Win7 Prof+ van, ott be is lehetne szántani a volume licenszes izét, egyszer kell a customsettings.ini-ben a MAC cím -> szériaszám hozzárendeléseket felvinni.)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Folytatva az MDT-s kisregényt a tegnapiakkal
--

Helyesbítés: a bdd_autorun.wsf helyett a Litetouch.wsf-et kell indítani, hogy ne kelljen ok-t nyomni az elején. Egy egyszerű scripttel, ami felcsatolja a deployment share-t egy alkalmas userrel, aztán elindítja a Litetouch-ot és egy kis psexec-el (hétfőn tudok írni pontos parancsot, már nem emlékszem, hogy kellett-e a UAC megkerülésére a runas) szépen indítható távolról. Még a logok formátumát kell meglesni, utána egyszerűen scriptelhető egy automatikus és egész jól bővíthető OS/alkalmazás telepítő.

A user state migration tool (<- az MS szabvány megoldása a user adatok költöztetésére, nem 100%, de működik) is működik, ahogy a backup is (<- ez egy wim-et csinál a teljes lemezről, a Windows ADK-ban levő dism-el fel lehet csatolni). Ennek a kettőnek a varázsló lapja elég sajátos: ahol ki lehet választani, hogy kell-e egyáltalán foglalkozni vele, ott van egy beviteli mező, ahol a helyet lehet megadni. Mellette egy tallózás gomb. A tallózás a helyi mappákat sorolja fel (PE környezetben még azokat sem), a mező elfogad kézzel beírt UNC útvonalat. USMT-nél működik a felcsatolunk egy hálózati meghajtót és azt betallózzuk játék, a Backup-nál nem, mert ott közben van egy PE-re váltás, úgyhogy nincs felcsatolva a meghajtó. UNC path-et megadva pedig futás közben mind az USMT mind a Backup szépen elhasal, egy szép nagy hibakódot visszaadva.

Az összegző lap szerint a varázsló a ComputerBackupLocation és UserDataLocation paraméterekbe írják be amiket megadunk. A manual szerint ezek értéke lehet AUTO (ha van elég hely, helyileg ment, ha nincs, hálózatra), NETWORK (mindenképp hálózatra ment a BackupShare/BackupDir és UDShare/UDDir paramétereknek megfelelő helyekre), NONE (nem csinál semmit) és UNC_path (ami ugye úgy tűnik nem működik). És a varázsló lapon nincs lehetőség a *Share/*Dir állítására. Egyelőre úgy működik, hogy azokat betettem a CustomSettings.ini-be, a varázslóban így NETWORK-ot beírva (yup... a tallózás gomb melletti szöveg mezőbe a "NETWORK" stringet...) megy a USMT/BackupDir.**

BlackY
**: Amíg ezt írtam jutott eszembe, hogy lehet az volt a gond, hogy a számítógépfiókkal próbálta felcsatolni a *BackupLocation-ben megadott share-t és az NT ACL-ek alapján tudott is volna ott írni/olvasni, de a megosztás beállításai miatt nem; a *Share/*Dir-rel megadottakat meg lehet, hogy a CustomSettings.ini-ben megadott acc-al próbálja, és ezért sikerül neki. Hétfőn meglesem.
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

További tapasztalatok az elmúlt pár napból és két-három sikeres deploy-ból:
* nem tudom írtam-e már (szerintem nem), de MDT 2012 Update 1 ajánlott az XP -> [Vista, 7, 8] migrációhoz, mivel az MDT 2013-ban levő USMT "Nem Win32 alkalmazás" címszóval nem indul el XP-n. Neten találni "megoldásokat", amik gyakorlatilag arról szólnak, hogy offline USMT legyen (a PE rendszerből indítva), így viszont a legfontosabbat (ti. beállított háttérkép) nem viszi át :(
* a virtualbox -> fizikai gép konverziót is gond nélkül túléli az MDT-vel telepített rendszer (mármint standard capture task sequence-el syspreppelt/készített image-t visszaállít fizikai gépre, ATA / SATA egyaránt)
* out-of-the-box nem tudja de könnyen megoldható az egyfajta hibrid deploy (alapesetben az MDT update és newinstall-t tud, utóbbi esetben formázza a vinyót, de ehhez CD-ről bootolva PE-ből kell indítani a task sequence-t, így csak offline user state migration lehetne, ami szívás és nem csinál backup image-t), amire nálunk szükség van, mert vannak még XP-k, amikről 1) kellene biztonsági mentés is a USMT-n felül és 2) újra kell partícionálni a HDD-t, mert alul van méretezve a rendszerlemez
- a USMT doksijában rendszerkövetelményként szerepel, hogy "Bármi, amin a forrásrendszer elfut", ami így is van, a hibakódok között (talán 29, nem esküszöm meg) viszont már szerepel, hogy legalább 250 mega szabad helyre szüksége van. Hozzáaadva az MDT saját cuccait olyan 500 mega, de egy giga alatt nem érdemes elindítani*
- ha backup is készül a lemezről (aminél tényleg működik a dedup/tömörítés, rohadt lassú, de egy kb. bzip-el partclone fájlméretét hozza és a futó rendszerben felcsatolható wim-et ad), akkor figyelni kell arra, hogy minden mentett partíción (van rá konfig property a CustomSettings.ini-ben) legalább annyi szabad területnek kell lennie, mint a legnagyobb mentett (!) fájl mérete (az imagex configjában [talán a Tools\wimsettings.ini vagy ilyesmi] van egy lista a kihagyott fájlokról/könyvtárakról [System Volume Information, pagefile, hibernate file ilyesmik])**
- out-of-the-box nem tudja, de a kattintgatós felületen meg lehet oldani (CustomSettings.ini-ben Properties-hez egy saját property, aztán ettől függővé tenni két task-ot a task sequence-ben) hogy az USMT-vel elkészítse az áttelepítőfájlt, de aztán ne használja (hogy mi értelme ennek? Vannak gépeink, ahol valszeg. nem lesz szükség a régi fájlokra, de ha igen, akkor USMT-vel vissza lehet egyben állítani mindent, nem kell az image-ből felcsatolt fájlrendszerben keresgélni. Ill. a két független back-up Jó Dolog (tm))
- ha az Apply PE után és az Install Operating System taskok között bárhol megborul a task sequence (hálózati hiba, tele levő meghajtó és a többi mulatság), akkor az XP bootképtelen maradt [az Apply PE feltelepíti/beállítja a Vista-ban megjelent boot managert és beállítja, hogy azonnal a PE-t bootolja, nem sikerült utána visszamennem XP-re fixboot nélkül]. Ezután ha visszajutottunk az XP-be és újra elindítanánk a task sequence-t, akkor az Apply PE lépésnél konzisztensen el fog halni a rendszer, a bootmgr fájlt és a boot mappát törölni kell a C:\-ről (Vistánál/7-nél állítana valami jogosultságot rajtuk [nem emlékszem mit] egy Vistában/7-ben megjelent parancssori toolal [nem emlékszem, melyikkel], XP ezt egy fájl nem található hibakóddal díjazza - ha viszont nem létezik a mappa/fájl, akkor simán bemásolja.)
- az állatorvosi ló teszt-laptopot is sikerült migrálni, azon ami előjöhet, elő is jött: tele levő rendszer ÉS adatpartíció, korábban domain-be volt léptetve, aztán kihúzva, így csomó SID sehova nem mutat

*, **: mindkettő megkerülhető 1-1 autoit exével, az első simán 0-t vagy 1-et ad vissza, ha van elég hely, ezt betéve a Validate csoportba még azelőtt leáll az egész folyamat, hogy bármi végelgeset csinálni, a másodiknál egy olyan scripttel játszottam, ami minden partíción végig nézi a fájlokat és megkeresi a legnagyobbat, ami nincs a tiltólistán, ha az nagyobb, mint a szabad terület, akkor áthelyezi a deploysrv-n levő megosztásba és újrakerestet, ha nem, akkor 0 exit code-al leáll

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Guest Additions nélkül maradnak a Windows saját driverei: annó XP egy IDE - SATA váltást már VirtualBox-ban sem élt túl, talán úgy igen, hogy előtte mutattam neki egy nem rendszerlemezt a SATA vezérlőn. (éles gépeken is ki fogom próbálni, de eddig pozitív az MDT)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( Benjamin v | 2014. 02. 25., k – 21:41 )

subscribe
-----
“Firefox, you say? No I don't play Pokémon”