Pokračovat ve čtení »]]> Chyba 0x0000006B  PROCESS1_INITIALIZATION_FAILED

nastává, pokud je špatně vygenerovan c:\windows\system32\codeintegrity\bootcat.cache

Tento soubor je generován při startu windows 7 ři 2008 R2 a mění se pokaždé když se změní databáze podisů ovladačů a aplikací c:\windows\system32\catroot (což znamená po každé instalaci čehokoliv vč. automatických aktualizací windows)

Pokud máte přístup ke stroji s podobnou konfigurací, můžete zkusit přenést tento soubor z něj. Pokud se však stroje budou lišit (např jinou verzí nějakého ovladače) pravděpodobně tím rozbijete konfiguraci a něco nebude fungovat – to je nepříjemné, pokud se Vám takto podaří rozbít např. ovladač grafické karty

Nejlepší způsob opravy je:

1. vyndat disk, připojit jej k fungujícímu stroji
2. zkontrolovat katalog podpisů \windows\system32\catroot\ zda obsahuje složku {F750E6C3-38EE-11D1-85E5-00C04C2295EE} a zda je v ní databáze certifikátů ovladačů tvořená několika stovkami až tisícovkami souborů certifikátů *.cat (přesný počet záleží na konkrétní konfiguraci stroje a na momentálně nainstalovaných updatech). Pokud tato složka chybí, je prázdná nebo obsahuje jen jeden soubor oemXX.cat (kde XX je nějaké číslo, např. oem19.cat), bude nutné nejprve vyhledat původní obsah a vrátit jej kam patří, případně se pokusit přenést obsah této složky z jiné instalace windows 7 / 2008R2 pokudmožno co nejvíce podobné té Vaší, jinak opět nebude něco fungovat.
3. Po úspěšné opravě, tedy obsahuje-li už složka catroot správnou databázi certifikátů, je pak možno soubor \windows\system32\codeintegrity\bootcat.cache smazat nebo přejmenovat aby při startu systému mohl být automaticky vygenerován nový.

A nakonec ještě poznámka k původnímu obsah složky \windows\system32\catroot\

Po diskuzních fórech se povaluje spousta “zaručených” návodů jak opravit chyby ve windows update. Většina jich doporučuje smazat c:\windows\system32\catroot2\, který se po opětovném spuštění služeb windows update (wuausvc) a šifrování (cryptsvc) vytvoří znovu. Poku však krom catroot2 omylem smažete či v lepším případě přejmenujete také složku catroot zaděláte si tím na problém, neboť tato složka se automaticky NEOBNOVÍ a přijdete tak o digitální podpisy (certifikáty) všech updatů a ovladačů, které jste si kdy nainstalovali do čisté instalace windows. Pokud by se teoreticky jednalo o čerstvou instalaci bez servicepacku a bez aplikovaných updatů, nic se nestane, ale v dnešní době je většina stojů s tímto starým operačním systémem plná doinstalovaných updatů a ovladačů, takže databáze catroot obsahuje i několik tisíc položek.

Pokračovat ve čtení »]]> Mám doma na půdě už nějaký ten rok svůj server. Když jsem se kdysi dávno při instalaci rozhodoval, který OS použiju pro nejnižší vrstvu virtualizace, tehdy jsem se rozhodl pro Windows server 2012 R2 CORE.  Důvody proč jsem nepoužil linux Xen nebo KVM byly spíš podružné, měl jsem prostě chuť vyzkoušet, jak budou linux guesti fungovat pod hyper-v. A taky zvědavost, japato že fachá ten Microsoftí server zdarma.

No nebyla to nejrozumnější volba: bez windows 8+ workstationu narazíte na věci, které cmdlety prostě udělat nejdou.Ale to  o tom až jindy.

Chtěl jsem dnes sdělit postřehy s tím falešným raid řadičem, za který se zřejmě AMD stydí a tudíž jej ani pořádně nepojmenovalo. Ano, řeč bude o Amd Optimal Raidu integrovaném v chipsetech SB7xx, SB850 a zřejmě i novějších.

Nevím jak dnes, ale dříve byly tyhle pseudo RAIDy nepříliš oblíbené pro svou nízkou výkonnost a hlavně protože to nebyly skutečné hw. řadiče, ale jen jakási nadstavba biosu, kterou se dal nějaký základní array nastavit. Veškeré další běžné činnosti pak řídil a vykonával hostitelský OS pomocí (také neoblíbených) proprietárních ovladačů.

V tomto jsem za uplynulých cca 10 let stále nezaznamenal žádný pokrok.

Je pravda, že dnes už vzhledem k výkonu aktuálních CPU a propustnosti sběrnic není zatížení CPU  vlivem administrace spojené s RAID řadičem již rozhodující, toho 1% ubraného z výkonu asi není nutno litovat.

Problém stále zůstává v tom, že tyto pseudo raidy jsou závislé na OS, a pokud opravdu nastane problém, tak jej nevyřešíte bez nabootování OS  a spuštění aplikace pro managment raidu. Což je ovšem dost chyba designu, neboť když už problém nastane, zpravidla to znamená, že nechcete pokračovat v bootování a riskovat, že dojde k úplnému rozpadu raidového pole a ztrátě dat.

Nicméně nedá se v tomto případě nic dělat. Pokud se v postu objeví nějaká chyba, je ten bios tak hloupý, že stejně v něm nejde nic opravit. Maximálně tak můžete  pokusit se pole zcela zrušit a sestavit znovu (pozor na initalisation, zřejmě o data nechcete přijít), ale výsledek je nezaručen a operace značně riskantní.

Největší fail je, když dojde k rozpadu / degradaci pole, pokusí se navíc pokračovat v bootování bez zásahu uživatele, což považuju za obrovskou chybu. Neboť samozřejmě, jakmile se na jeden ze dvou disků v raid1 šáhne, dojde k nenávratnému rozpadu pole, neboť si potom obrazy binárně neodpovídají. A to se také stalo. Omylem jsem zapojil jeden z disků do špatného sata portu (jež nebyl aktivní), a ten pitomý raid management jen asi na vteřinu zobrazil varování. Než jsem stačil zasáhnout už pokračoval v bootování a bylo to. Raid se mi rozpadl a sesynchronizovat jej znovu nebylo čím.

Nepříjemné je, že v případě amd je managment aplikace (zvaná RaidXpert tool) určena dle popisu pouze pro Win 7, Win8, Win8.1. a win 10. No řekněme, že pokud běží na Win 8 / 8.1, mohlo by to jít i na  Win 2012 / 2012 R2… ale garantováno to jaksi není….. Ale co CORE server? nikde ani zmínka sakryš…

(pokračování příště)

Pokračovat ve čtení »]]> Už se Vám také stalo, že Vám někdo pravděpodobně nechtěně nebo dokonce se zlým úmyslem smazal nějaký soubor, který jste ještě před týdnem měli na síťovém disku ve sdílené složce a dnes ho nemůžete najít?

Nebo si nejste jisti, zda jste si ho přeci jen omylem smazali sami?

Pokud používáte windows server jako souborový server a nemáte svoje soubory dostatečně izolované od ostatních uživatelů, snadno dojde ke ztrátě souborů. Jde věšinou o chybu v konfiguraci, nebo o zapomenuté chybné nastavaní zabezpečení konkrétního jednoho souboru. Ale někdy je to také záměr – pokud pracuje více lidí na stejné věci, bývá jednodušší mít sdílení i s právem zápisu pro ostatní uživatele. Avšak potom se nesmíme divit, že semtam dochází k nechtěným přepsáním či ztrátám.

Jak tedy dohledat, co se Vašemu souboru stalo? – Snadná pomoc:  od verze 7/2008 R2 výše je k dispozici užitečná věc:

Nástroje pro správu / Místní zásady zabezpečení / upřesnit konfiguraci zásad auditování / přístup k objektu / auditovat systém souborů

Administrative tools / local security policy / advanced audit security configuration/ object access / audit file system

povolíme zde obě možnosti (úspěch i neúspěch).

Zatím se nic nestane, dokud ve vlastnostech sdílené složky (buď vlastnosti složky na lokálním disku serveru nebo vlastnosti sdílené složky ve správě počítače) :

zabezpečení / upřesnit / auditování

 

security / advanced / auditing

nastavíme, jaké operace se budou zaznamenávat v logu.

Doporučuji nastavit minimálně úspěšné pokusy o smazání, změnu oprávnění a převzetí vlastnictví.

V systémovém logu (“zabezpečení” resp. audit) pak máme záznamy o všech výmazech a podezřelých operacích, samozřejmě včetně přesného času a už. účtu, ze kterého byly operace provedeny.

Pokračovat ve čtení »]]> V logu Powershellu se mi sporadicky, cca 1x denně začaly objevovat chyby související s WinRM podobné této:

WSMan reported an error with error code: -2144108453. Error message: Closing remote server shell instance failed with the following error message : Vzdálené prostředí systému Windows nemůže žádost zpracovat. Hodnota voliče xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, určená v žádosti, nebyla nalezena. For more information, see the about_Remote_Troubleshooting Help topic.

Dlouho jsem nemohl přijít na to, čím to, že se najednou tyto chyby začaly vyskytovat. Myslel jsem nejprve, že to souvisí s aktualizacemi zabezpečení, které jsem před nedávnem schválil k instalaci – časově to celkem odpovídalo prvnímu výskytu. Pátrání tímto směrem ale nikam nevedlo.

Tak nastoupilo docela zdlouhavé googlování na technetu, které odhalilo skutečnou příčinu:

Uvědomil jsem si, že jsem před pár týdny v rámci ladění výkonu nastavoval limity soukromé paměti Worker-procesů IIS, aby mi taky nějaká volná pamět zbyla na důležitější procesy (IIS používáme jen pro správu Exchange a pro OWA). Bohužel se nepříznivé následky nastavení těchto limitů začaly projevovat až s cca týdenním zpožděním – trvalo to zkrátka příliš dlouho, než byl nově nastavený limit skutečně dosažen. Proto mě také ze začátku nenapadlo, že by tyto události mohly spolu souviset.

Jenže zrovna worker proces MSExchangeServicesAppPool prý nesnáší, když se ho pokoušíte nějak omezovat. Zmínku o tom jsem našel v tomto threadu.

Proto tomuto worker-procesu nenastavujte žádné limity, a raději nechte všechna nastavení výchozí – vyvarujete se tak podobným komplikacím s WindowsRM resp. s Powershellem

Pokračovat ve čtení »]]> Poté, co jsem zprovoznil koexistenci Apache a IIS na portu 80 na různých IP adresách, začly se v logu Apache pravidelně cca jednou za 30 minut objevovat neúspěšné přístupy k adresáři /PowerShell

/Powershell je webové administrační rozhraní pro správu a údržbu (nejen) Exchange pomocí služby Windows Remote Management a je umístěn ve výchozí webové složce v IIS7.

Také se současně pravidelně v syslogu objevovaly chyby:

PowerShell (Microsoft-Windows-PowerShell) 32784

a

Windows Remote Management  130

Dále rovněž nefungovala Exchange management console (EMC), která při spuštění hlásila chyby související s ověřováním Kerberos a jiné nesmysly.

Protože po vypnutí Apache vše zas začalo ihned fungovat, vypadalo to, že prostě hloupá EMC musí mít přístup k adresáři /Powershell na všech otevřených portech 80, jinak zkolabuje.

Přesměrování adresáře /Powershell v httpd.conf na jinou IP přes Http.301 ani 302 nepomohlo.

Zjistil jsem ale, že se EMC připojuje pouze k první IP adrese v pořadí –  té s nejnižší číslicí na konci. O ostatní adresy se již nezajímá. Bohužel, zrovna v mém případě jsem tu první adresu vyhradil pro Apache.

Tudíž jsem před IP adresu určenou pro Apache (192.168.0.5) přidal ještě jednu IP adresu vyhrazenou pro IIS s nižší poslední číslicí (192.168.0.4) 

poté ještě je potřeba nastavit ISS aby naslouchal i na nově přidané IP adrese podle tohoto postupu

 a je to!! Konzole se už spojuje, chyby z logu zmizely

Pokračovat ve čtení »]]> S novou verzí Exchange se vyrojila spousta vtipných situací – třeba taková chyba 80040A02

Docela jsem byl překvapen, že málokteré chybové události jsou řešeny oficiální technickou podporou – Je tomu právě naopak, většinou je řešení totiž nutné hledat na různých komunitních webech.

Exchange mám schovaný až  za linuxovým SMTP serverem (postfix + mailscanner) v privátní IPV4 síti, tudíž IPv6 skutečně nepotřebuji (a i kdybych ho chtěl, stejně ho náš ISP neposkytuje, jak je stále v ČR obvyklé)

Jeden opravdu zábavný zážitek byl, že po vypnutí nepotřebného IPv6 protokolu a restartu systém zatuhl na vítací obrazovce (Nastavení počítače…) aniž by nabídl přihlašovací dialog

Naštěstí se spustily alespoň nějaké základní služby, takže jsem se mohl podívat z jiného pc přes computer management do logu a na stav služeb.

Zjistil jsem, že se Exchange (Exchange store, Exchange transport, Exchange MTA atd) odmítají spustit a v applogu jsem našel chybu

MSExchange ADAccess 2114:

80040A02 (DSC_E_NO_SUITABLE_CDC)

Opětovné zapnutí protokolu IPv6 v nouzovém režimu se sítí tento problém vyřešilo.

(taky by to šlo zapnout přes registry v HKLM/SYSTEM/Currentcontrolset/services/tcpip6)

řešení je k nalezení zde, ale zato oficiální technická podpora stále mlčí (ano, ano, odkaz je správně!)

Pokračovat ve čtení »]]> Potřeboval jsem koexistenci IIS7 a Apache na stejné mašině na různých IP adresách, oba na portu 80.

IIS  mívají zapnutý tzv. socket poolig, což znamená, že na portu 80 naslouchají na všech IP adresách na všech adaptérech

U dřívější verze IIS (6) si nepamatuji, že bych to musel řešit , ale u IIS7 je nutné nejprve socket pooling vypnout tím, že se specifikují konkrétní IP adresy, na kterých má naslouchat dle tohoto návodu

netsh

http

add iplisten ipaddress=192.168.0.1

exit

Tím se nám uvolní druhá IP adresa, na kterou pak pověsíme Apache.

A je to!

pozn. pokud máte na stejném stroji také Exchange, přečtěte si prosím ještě toto