Je to už rok a půl, co jsem si trhal vlasy nad nemožností přidat do již nainstalovaného a nakonfigurovaného Hyper-V clusteru, založeného na Windows Serveru 2008 R2, dodatečné síťové karty. Jednou nainstalovaná Core edice prostě ani zaboha nechtěla rozpoznat nově přidané síťové karty. Zkoušel jsem tenkrát rušit týmy, reinstalovat BACS (byly to Broadcomy), zkoušel jsem pomocí “pnputil.exe –d oemX.inf” odinstalovat ovladače síťových karet. Všechno marné, nově přidané síťovky jsem v OS nezprovoznil, takže jsem musel přistoupit ke kompletní reinstalaci všech tří serverů.
Od té doby mám docela panickou hrůzu, že se u nějakého Core serveru objeví potřeba přidat další síťovou kartu, případně vyrobit kvůli VLAN, u něhož by nebylo možné použít trunk, nějakou další virtuální síťovou kartu, kterou by Core edice zase nerozpoznala. Dnes jsem objevil KB2460786, který by snad mohl v těchto případech pomoci. Více...
Dnes mne zaskočila při připojení k SBS 2011 následující hláška: “The task you are trying to do can't be completed because remote desktop services is currently busy. Please try again in a few minutes. Other
users should still be able to log on.” Standardní přihlášení nešlo, zabrala poté až varianta s /admin přepínačem v názvu volaného serveru.
Začal jsem se pídit po informacích, o co jde. Našel jsem tento záznam na Experts Exchange. Zde byl odkaz na KB2383928. V tomto článku jsou popsány závady v ovladači Win32k.sys, díky němuž může za určitých podmínek dojít k vyčerpání zdrojů, kdy server začne odmítat nové RDP spojení, což by docela odpovídalo chování serveru. Co je ale horší, při pokusu o restart může dle článku dojít k zablokování shutdown procesu. Údajně pak nezbývá nic jiného, že natvrdo server vypnout a zapnout (což může mít teda parádní efekt na konzistenci všech LDAP, DHCP, Exchange, SQL databází, konzistenci HW či SW RAID). Takže před restartem raději preventivně manuálně stopnu všechny podstatné služby, u nichž to lze a u kterých by mohlo dojít k nakopnutí dat, např. DHCP, Exchange, SQL. Více...
Nedávno vyšly aktualizované Remote Server Administration Tools (RSAT) pro Windows 7 SP1, které zpřístupňují admin. nástroje vůči W2008 R2 SP1 serveru i na stanicích, na kterých byly Windows 7 nainstalovány rovnou s integrovaným SP1 (doteď bylo nutné instalovat nejdříve W7, pak RSAT a pak separátně W7 SP1). Stahovat je možné zde - http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d.
Druhý odkaz je MS Hyper-V Server 2008 R2 s integrovaným SP1. Ten roste zde - http://www.microsoft.com/downloads/details.aspx?familyId=92E2C4BA-6965-4F8E-ABBE-CBB40556B680
Aktualizace 21.3.2011: Na blogu Microsoftu se objevila informace, že níže uvedený článek KB975484 byl rozšířen o .VBS skript, který pomůže všem, kteří se dostali k chybě 0xc0000034. Bacha, je nutné přepnout na anglickou verzi článku, v češtině ty informace zatím chybějí. Zároveň článek pomůže pouze těm, kteří aktuálně trpí uvedenou chybou, nepomůže těm, kteří si pomohli úpravou xml nebo odmazali SetupExecute. Takže pro mnoho lidí přichází MS s řešením s křížkem po funuse.
Dnes na nás čekalo nepříjemné překvapení na několika pracovních stanicích a noteboocích, na nichž se večer při vypínání objevila hláška, že se bude instalovat SP1 z WSUS. Předem podotýkám, že jsme aplikaci SP1 testovali a nenarazili na problém – jak se ale dnes ukázalo, testovali jsme nedokonale. Více...
Každé AD by mělo být pravidelně monitorováno, aby neobsahovalo vyhnilé účty, jak počítačů, tak lidí. Ne všude to funguje tak, že člověk odchází ze společnosti a automaticky jsou smazány všechny jeho účty. Je to také oblíbenou otázkou auditorů. Takže přijde vhod jednoduchý baťáček, spouštěný pravidelně v rozumných intervalech (denně/týdně), který projde komplet doménu a vyhledá mrtvoly. Více...
Tahle věc mě vytáčela řadu měsíců, vlastně roků. Nebyla ale tak důležitá, abych se tomu věnoval až do úspěšného vyřešení. Až teď. Doména, kterou v práci používáme, má prazáklady už z Windows 2000 a je postupně upgradována, schéma rozšiřováno, AD řadiče i jména domén přejmenovávány, nahrazovány atd. Až do doby nasazení Windows Vista (někdy před čtyřmi lety) jsem i z domova přes VPN bez problémů přistupoval k DFS zdrojům. Pak se něco změnilo a přístup přes DFS rozcestník přestal fungovat, takže jsem se smířil s nouzovým přístupem na cílové sdílené adresáře na příslušných serverech. Místo tvaru \\domena.local\dfs\adresar jsem si tak holt mapoval přímo \\server.domena.local\adresar.
V minulých dnech jsem ale musel řešit problém s Windows XP, které nedokázaly korektně komunikovat s AD řadiči W2008R2 (o tom ale až v následujícím článku) a při té příležitosti jsem narazil i na problém DFS přes VPN. A teď už vím, co jsme kdysi hodně dávno udělali špatně. Více...
Člověk by čekal, že když má server udržovaný, s aktuálními servisními balíčky a hotfixy, tak je v pohodě. Opak je však pravdou – je více než záhodno utahovat vše, co jde. A jednou z oblastí, které je dobré kontrolovat na všech verzích Windows Serveru, je SSL.
IIS od verze 5 volil protokoly v tomto sestupném pořadí – PCT 1.0, SSL 3.0, SSL 2.0. PCT 1.0 a SSL 2.0 jsou již obecně považovány za slabé, od Windows 7 a Windows Serveru 2008 R2 již nejsou ze strany klienta používané. Bohužel je však i ve Windows 2008 SSL 2.0 standardně zapnuté, takže si jej může případný útočník vynutit (řekne serveru, že nepodporuje SSL 2.0).
Platí, že TLSv1 = SSLv3. U starších OS je ještě doporučeno zakázat slabé šifry DES 56/56, NULL, RC2 40/128, RC4 40/128, RC4 56/128. Ty jsou opět u Windows Serveru 2008 R2 standardně vypnuté.
Nejsnazší cestou, jak zjistit aktuální stav, je spustit některý z online testů: Více...
Před rokem a půl jsem si v tomto článku poznamenal konfiguraci souběžného fungování IIS 7 a Apache na jednom serveru. Ne že by to v IIS 7.5 bylo jinak, začíná se však kromě IPv4 používat i IPv6, tak si neuškodí poznamenat ještě pár drobností.
Příkaz netsh s níže uvedenými parametry upravuje tento záznam v registrech - HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, ListenOnlyList. Více...
V novém roce plný elánu po prodělané nemoci jsem se pustil do dlouhodobých restů. Jedním z nich byly chyby v DPM 2010 serveru. Těch se objevilo hned několik, jednou z nich bylo opětovná deserializace záloh virtuálních mašin na CSV clusteru, předpokládám, že to způsobila instalace posledního DPM rollup hotfixu. Takže si holt do dokumentace píšeme poznámku, že po každém patchování DPM serveru je potřeba pro jistotu kontrolovat nastavení klíče HKLM\SOFTWARE\Microsoft\Microsoft Data Protection Manager\2.0\Configuration\MaxAllowedParallelBackups\Microsoft Hyper-V, které musí obsahovat číslo 1 a nikoliv standardní 3. Další typ chyby, který se projevoval pouze u dvou virtuálních serverů, byl ještě záludnější. Ukázalo se nakonec, že problém je v kolizi Master Boot Record signatur disků. Více...
Už několik dní si rvu vlasy nad DPM2010. Původní server obsahoval W2008R2, na němž běžela nejprve Beta verze DPM2010, posléze upgradovaná na RC a pak na RTM. Známou chybou je, že takto získaná finální instalace trpí na expiraci jak MS SQL Mgmt. studia, tak expiraci samotného SQL serveru. Nakonec jsem se naštval, odinstaloval vše, co zavánělo DPM2010 a SQL2008 a začal z čisté vody. Původní DMPDB databázi jsem si zazálohoval.
Vše proběhlo ok, prošel jsem si jednotlivými kroky obnovy DPM serveru, ručně spouštěné vytváření replik či recovery points funguje parádně, ale zaboha se nechtějí vytvářet repliky a recovery points pomocí časovače. V eventlogu se objevovala v době, kdy mělo dojít k vytvoření repliky nebo recovery pointu, takováto chybová hláška: Více...