Tipy a triky

Je opravdu RODC (Read Only Domain Controller) jen pro čtení?

Jiří Hýzler — Sun, 01 Feb 2009 19:59:34 GMT

Než odpovím na otázku v titulku, možná někdo netuší co je to RODC, proto si dovolím nejprve popsat tento typ řadiče.

RODC je novým typem řadiče domény ve Windows Server 2008. Pamětníci Windows NT by mohli namítnout, že zase tak nový typ řadiče to není, protože už v NT byl tzv. BDC (Backup Domain Controller), který by podle názvu RODC odpovídal. Je pravda, že skutečně stejně jako kdysi BDC uchovává nový řadič kopii adresářové databáze pouze pro čtení, ale současně nabízí mnohem více funkcionality.

Hlavními vlastnostmi RODC jsou:

Active Directory (AD) databáze pouze pro čtení.
- Aplikace, které potřebují pouze číst z AD, mohou využívat RODC. Jakmile ale potřebují provést změnu v databázi, musí se obrátit na „zapisovatelný“ DC, tzv. RWDC (Read Write Domain Controller), ze kterého se změna replikuje zpět na RODC.
- Application Compatibility with RODCs: http://technet.microsoft.com/en-us/library/cc754165.aspx
Jednosměrná replikace.
- Směrem z RODC se nic nereplikuje (i kdyby na něm byla změna přímo provedena – např. něco byste smazali v SYSVOLu). Jednosměrná replikace pouze na RODC snižuje komplexnost replikační struktury a snižuje riziko replikace změn z poboček, kde bývá nejčastěji RODC nasazen a kde většinou bývá menší míra zabezpečení serverů.
Filtrované atributy (Filtered Attribute Set – FAS)
- Administrátor může specifikovat atributy (kromě system-critical atributů), které se nebudou replikovat na žádný RODC v lese. To může zamezit vyzrazení některých informací v případě kompromitování RODC.
- Steps to Add an Attribute to the RODC Filtered Attribute Set: http://technet.microsoft.com/en-us/library/cc772331.aspx
Omezení kešování hesel
- Jeden z největších benefitů. Po instalaci RODC neuchovává žádná uživatelská ani počítačová hesla pro přihlášení (kromě vlastního počítačového účtu RODC a krbtgt). Když obdrží požadavek na autentizaci, tak ho automaticky přeposílá na RWDC. Administrátor může nastavit skupinu uživatelských účtů a účtů počítačů, jejichž hesla budou kešovány na RODC (typicky pouze pro zaměstnance pobočky a jejich počítače). Pak tyto účty jsou autentizovány přímo RODC bez použití RWDC. Důvodem omezení replikace hesel na RODC je bezpečnost. V případě kompromitování RODC nemá útočník způsob jak získat hesla např. administrativních účtů v doméně, protože tyto účty se nekešují na RODC, tj. nejsou fyzicky na tomto serveru (pro tyto účty se autentizace provádí na RWDC, který je typicky umístěn jen v centrále). Kompromitované účty zaměstnanců pobočky je navíc možné rychle a hromadně resetovat smazáním účtu počítače RODC na RWDC.
- Více o kešování hesel a fungování autentizace na RODC se dočtete zde: http://technet.microsoft.com/en-us/library/cc754218.aspx
Admin role separation
- Většinou na pobočce DC nezastává pouze funkci repliky AD, ale jsou na něm nainstalovány i další služby. V předchozích verzích bylo obtížné delegovat administraci na pobočkovém řadiči domény, protože buď jste museli delegovaného uživatele zařadit do doménových administrátorů (a tím mohl provádět i změny do AD) nebo jste ho mohli zařadit do skupiny Server Operators a tím sice nemohl provádět změny do AD a při tom měl administrativní oprávnění k operačnímu systému serveru, ale zároveň tím získal možnost administrovat všechny OS řadičů domény v celé doméně. Nyní máte možnost svěřit delegovanému uživateli jen administrativní oprávnění k OS jen na jeden konkrétní řadič domény (např. pro možnost restartovat nějakou aplikaci, aplikování aktualizací, instalaci ovladačů apod.)
Podpora DNS služby
- I DNS server umí fungovat na RODC a i on je pouze pro čtení. Pro konfiguraci DNS není potřeba nic zvláštního nastavovat (postupuje se stejně jako u RWDC), jen všechny požadavky na zápis do DNS databáze budou automaticky přeposílány na RWDC.
Dvou-fázová instalace RODC
- Administrátor může předem na RWDC vytvořit účet pro nový RODC (computer i server object) a delegovat uživatele, který může následně provést instalaci konkrétního RODC. Uživatel pak např. v pobočce už jen spustí instalaci, která může být i navíc automatizována pomocí odpovědního souboru.

RODC může replikovat pouze z Windows Server 2008 RWDC, proto je potřeba alespoň 1 mít nainstalován. Replikace z Windows Server 2003 DC nebo z RODC není možná.

RODC je téměř ideální nasazovat na pobočkách. Na pobočkách totiž je mnohem méně věnovaná pozornost bezpečnosti serverů a to jak fyzické, tak i logické. Většinou na pobočce nebývá stále přítomen administrátor, z prostorových důvodů servery (a tedy ani řadič domény) nebývají uzamčeny v serverovně, ale jsou umístěny přímo v kanceláři (v lepším případě jsou uzamčeny v racku, ale už jsem viděl je i povalovat se na společné chodbě, protože moc hučely). Není tedy divu, že k serverům a DC mají přístup na pobočkách obyčejní zaměstnanci a bohužel i v mnoha případech cizí osoby.

RODC není samospasitelným řešením bezpečnosti DC, ale v kombinaci s instalací na Windows Server 2008 Server Core a technologií BitLocker výrazně zvyšuje bezpečnost tohoto serveru.

Obr: Fyzická bezpečnost DC na pobočce.

A nyní se vrátím konečně k otázce z titulku tohoto článku, zda může RODC zapisovat do vlastní databáze.

RODC má skutečně databázi AD jen pro čtení až na jednu skupinu atributů. V běžné situaci, pokud se pošle na RODC zápisová operace, RODC přesměrovává požadavek na RWDC, který pak tuto změnu replikuje zpět na RODC. Konkrétně, jestliže aplikace se pokusí zapsat na RODC, RODC ji odpoví referencí, informující aplikaci, že by měla svůj požadavek na zápis nasměrovat na RWDC. Pokud aplikace nepodporuje reference, nejspíše nebude fungovat (proto byste je měli důsledně otestovat, než je nasadíte na RODC – viz odkaz výše „Application Compatibility with RODCs“.

Představte si ale situaci, kdy pobočkové RODC nebude mít konektivitu k žádnému RWDC a v té době se někdo pokusí hacknout uživatelský účet nějakým password attackem. Za normální situace, by se na RWDC automaticky inkrementoval atribut BadPwdCount a jakmile by útočník dosáhl počtu povolených pokusů definovaných v politice hesel (v GPO nebo v PSO), účet by byl uzamčen. Protože ale RODC by nemuselo mít konektivitu k RWDC, které by zvýšilo čítač BadPwdCount (to by byla zranitelnost RODC, protože účet uživatele by se nikdy neuzamkl), tak z tohoto důvodu RODC může zapisovat ve vlastní databázi atribut na počet chybných pokusů a přihlášení, tedy BadPwdCount a také atribut LastLogon, aby umožnil případné zamčení účtu.

Jeden starší tip na bootovací CD s XP

Jiří Hýzler — Sun, 01 Feb 2009 15:12:24 GMT

Pokud si vypalujete vlastní CD s instalací operačního systému Windows XP, např. aby jste si integrovali SP3 rovnou do instalace (postup vytváření CD je např. zde: http://www.cdr.cz/a/1173 nebo zde: http://www.cdr.cz/a/5332 ), tak jste možná narazili na chybu čtení souborů cyclad-z.inf a cyclom-y.inf během instalace OS.
Tato chyba je způsobena při vypalování CD, protože použijete formát ISO-9660 místo Joilet, který dovoluje znak pomlčky.

A ješte jeden tip: Pokud máte nainstalované Windows XP a musíte např. vyměnit základní desku, tak můžete narazit na chybu INACCESSIBLE_BOOT_DEVICE, tak by Vám mohl pomoci návod na: http://www.cdr.cz/a/3687 nebo rady na http://smallvoid.com/article/winnt-inaccessible-boot-device.html (zde je jich víc pro NT až WS2003)

Co je to SYN attack?

Jiří Hýzler — Sun, 01 Feb 2009 15:10:02 GMT

SYN (TCP požadavek na spojení) je útok, který spadá do skupiny Denial of Service (DoS) a dal by se charakterizovat takto:

Použitím podvržené (spoofed) IP adresy (typicky nepoužívané na Internetu), útočník pošle několik SYN paketů na cílový počítač.
Pro každý SYN packet, keterý cílový počítač obdrží, musí alokovat prostředky a poslat SYN-ACK potvrzení na zdrojovou IP adresu.
Protože cílový počítač neobrží odpověď (ACK) z útočícího počítače, že dostal v pořádku SYN-ACK potvrzení, posílá znovu útočícímu počítači paket SYN-ACK a to celkem 5x v 3, 6, 12, 24 a 48 vteřinových intervalech s nadějí, že vytoužený ACK paket od útočícího PC dostane. Po celou dobu ale musí držet alokované prostředky, než po posledním neúspěšném pokusu je bude moci uvolnit.

Když útočník používá tuto techniku opakovaně, je jasné, že cílovému pocítači brzy dojdou prostředky a nebude schopen akceptovat další spojení a tím odepře služby legitimním uživatelům.

Pro zjištění, zda Váš systém může být zranitelný vůči tomuto typu útoku, napište v příkazové řádce:
netstat -n -p tcp
a podívejte se na řádky, které obsahují status SYN_RECEIVED. Jestliže uvidíte hodně těchto položek, Váš systém je zranitelný na tento útok.

Ochranu Vám samozřejmě poskytne kvalitní firewall, ale i ve Windows je možné pomoci ochraně proti DoS útokům a zkrátit časy pro SYN požadavky. Stačí když v registrech v cestě HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters v DWORD hodnotě SynAttackProtect budete mít nastavenu hodnotu 2.

Pozn.: Hodnota 0 v SynAttackProtect znamená žádnou ochranu. Hodnota 1 omezuje počet SYN opakovaných pokusů a čekacích dob, když je dosažen maximální počet otevřených TCP spojení (TcpMaxHalfOpen), tedy spojením ve stavu SYN_RECEIVED, a když je dosažen maximální počet opakovaných pokusů (TcpMaxHalfOpenRetried). Hodnota 2 v SynAttackProtect funguje podobně jako hodnota 1, ale navíc zahrnuje zpoždění Winsock notification dokud se nedokončí celé three-way handshake (tedy celé TCP spojení). Protože Windows vyvolá SynAttackProtect až po dosažení hodnot v TcpMaxHalfOpen a TcpMaxHalfOpenRetried, doporučuji nastavit i tyto hodnoty v registrech na 100 resp. 80.

Další parametry TCP/IP pro hardening najdete v mém starším článku: http://blog.hyzler.net/archive/2007/07/06/11.aspx

Test rychlosti připojení k Internetu

Jiří Hýzler — Sun, 01 Feb 2009 14:44:22 GMT

Asi si říkáte, že takových testů je všude spousta, ale tenhle je přeci jenom trochu vyjímečný. Obvykle tyto služby totiž testují jen konektivitu k danému webu nebo poskytovateli a bohužel nevypovídají nic o tom, jakou konektivitu máte např. do různých států. Na této adrese (http://www.dslreports.com/speedtest?more=1) najdete rozcestník odkazů na testy rychlosti v různých částech světa (ČR je tam také :-) ), navíc jsou zda i testy specielně pro mobilní telefony (máte možnost si vybrat různé velikosti dat).

Pokud se zdarma zaregistrujete, budete mít k dispozici i další testy např. na kvalitu linky připojení. Testů je tam celá řada, některé služby jsou už pak pro premium registrace, tedy placené.

Na druhou stranu ne všechny testy mi fugovaly, což mohlo být ale způsobeno mým vysokým stupněm zabezpečení mého domácího PC a firewallů. :-)

Zde je adresa: http://www.dslreports.com/tools

Alternativní klienti pro Windows Remote Desktop

Jiří Hýzler — Wed, 09 Apr 2008 09:41:16 GMT

Představovat RDP klienta snad ani nikomu nemusím, pokud ale každý den používáte tohoto připojení k několika serverům, brzy vás přestane bavit neustále vyplňovat jméno nebo IP adresu počítače a další nastavení a začnete se poohlížet po nějakém "lepším" řešení.
Můj kolega Petr Bouška o tom napsal pěkný článek, který si můžete přečíst zde: http://www.samuraj-cz.com/clanky/administrace/alternativni-lepsi-klienti-pro-windows-remote-desktop/, kde srovnává několik zdarma řešení.
Pro úplnost jen doplním odkaz na změny v RDC 6.1: http://blogs.msdn.com/ts/archive/2007/12/17/changes-to-remote-administration-in-windows-server-2008.aspx.

Přechod na Exchange Server 2007

Jiří Hýzler — Tue, 11 Mar 2008 11:05:13 GMT

Tento článek není step-by-step návodem jak provést migraci na Exchange Server 2007, na to jsou školení a jiné weby, ale spíše dává pár užitečných rad na co si dávat během migrace pozor nebo co provést po instalaci. To co budu dále popisovat se týká organizace s jedním Exchange Serverem 2003, pokud máte více serverů, různé verze, napojením na produkty třetích stran, tak samozřejmě ten přechod může být složitější. Jako MAPI klienty předpokládám MS Office Outlook 2007. Máte-li nějaké další tipy, vůbec se jim nebráním.

Příprava
Zdůrazňuji, aby jste přípravu rozhodně nepodceňovali, protože se vám to později může krutě vymstít. Tak předně důkladně zkontrolujte požadavky pro instalaci Exchange Server 2007 a když říkám zkontrolovat, tak tím opravdu myslím zkontrolovat (ne jako se mi stalo u jednoho zákazníka, který mě neustále ujišťoval, že má nainstalované příslušně service packy a po té co proces migrace zkolaboval, se ukázalo, že je tam nemá).
Microsoft má na to pěkný checklist: http://technet.microsoft.com/en-us/library/bb125239.aspx

Dalším krokem je kontrola systémových požadavků pro Exchange 2007 a příprava Active Directory na Exchange 2007. Rozcestník na tyto kroky je třeba zde: http://technet.microsoft.com/en-us/library/bb123517.aspx

Zvláštní poroznost věnujte zejména přípravě Active Directory. U zase jiného zákazníka se mi stala velmi podivná věc. Všechny parametry (/PrepareLegacyExchangePermissions, /PrepareSchema, /PrepareAD i /PrepareDomain) setup.com se provedly OK bez zjevné známky chyby. Dokonce i instalace kupodivu proběhla na první pohled v pořádku, ale už na ten druhý podle silně červenajícího Event logu tomu tak nebylo. Chyby byly téměř nic neříkající, jen jediným vodítkem bylo cannot query Active Directory - access denied. K mému překvapení byly sice všechny Exchange skupiny založeny v AD v kontejneru Microsoft Exchange Security Groups, ale nikdo nebyl členem ani v jedné z nich. Dále jsem zjistil, že chybí i uživatelská práva (user rights) pro tyto skupiny a chybí i některá oprávnění na kontejner Microsoft Exchange v konfigurační partition AD. To že se něco nenastavilo, by mi tolik nevadilo (může to být způsobeno silným zabezpečení AD), spíš mi vadí, že mi to všude psalo completed a nic mě to neupozornilo. No nic, stalo se mi to jen jednou, třeba to byla shoda nějakých náhod.
Každopádně užitečný dokument, který mi tenkráte pomohl, bych vám doporučil v každém případě si přečít, mimo jimé je tam vysvětleno co se děje při "modifikaci" AD a jak to zkontrolovat a popř. napravit:
White Paper: Preparing Active Directory for Exchange 2007 - http://technet.microsoft.com/en-us/library/bb288907.aspx

Kontrolu po instalaci Exchange, textových setup logů, startování běžících služeb nebo odeslání e-mailu mezi dvěma uživateli snad ani nemusím připomínat.

Migrace (s koexistencí)
Dále budu popisovat situaci, kdy v jedné Exchange organizaci vám nyní běží stávající Exchange 2003 a nový Exchange 2007 a budete chtít přestěhovat všechny služby a data na nový a starý Exchange nakonec odinstalovat.

Po instalaci nového Exchange serveru 2007, je potřeba propojit routing groups pomocí Routing Group Connector a zakázat propagaci link-state updates:
How to Suppress Link State Updates - http://technet.microsoft.com/en-us/library/aa996728(EXCHG.80).aspx
How to Create Routing Group Connectors from Exchange 2007 to Exchange Server 2003 - http://technet.microsoft.com/en-us/library/aa997292(EXCHG.80).aspx

Pozn.: Po odstranění posledního serveru z routing group, můžete routing group smazat.

Pro další kroky vám poslouží návod "How to Remove the Last Legacy Exchange Server from an Organization" - http://technet.microsoft.com/en-us/library/bb288905. K tomu jednu poznámku. Dejte si pozor při přesunu veřejných složek, zda jsou opravdu všechny instance složek přesunuty, může to totiž trvat (EXCHG.80).aspxi několik hodin (podle množství dat). U jednoho zákazníka se mi stalo, že dvě složky nějak vzdorovaly a nechtěly se přesunout. Tak si můžete pomoci MS Office Outlookem, přetáhnout je do .pst souboru a až bude "po všem", tak je šoupnout na nový Exchange (pro jistotu si poznamenejte i oprávnění k těmto složkám). K tomu ještě jeden článek: How to Remove a Public Folder Database in Exchange Server 2007 RTM - http://msexchangeteam.com/archive/2007/07/09/445967.aspx

Po úspěšné odinstalaci posledního Exchange 2003, můžete provést pár kroků pro "znativnění" některých nastavení.

Doporučil bych upgradovat Email Address Policy a Address Listy, návod jak na to je zde:
Address List and EAP filter upgrades with Exchange Server 2007 - http://msexchangeteam.com/archive/2007/01/11/432158.aspx

Konverze mailboxu reprezentujícího nějaký prostředek (auto, zasedačku, projektor,...) na "Resource Mailbox" (např. pro to, aby jste mohli nastavit kapacitu prostředku):
Set-Mailbox <Mailbox který má být převeden> -Type Room
Set-Mailbox <Mailbox který má být převeden> -Type Equipment

Pokud si chcete vypsat, které mailboxy jsou již Resource Mailboxy:
Get-Mailbox <Mailbox> | select Name,IsResource

BTW. hezký článek o plánování prostředků, AutoAccept, delegaci je zde: http://msexchangeteam.com/archive/2007/05/14/438944.aspx (Resource Scheduling in Exchange Server 2007).

Doporučil bych i nastavit externí postmaster adresu na všech HUB transport serverech:
Get-TransportServer | Set-TransportServer -ExternalPostmasterAddress <ExternalPostmasterSMTPAddress>

Změnit default banner na SMTP receive conncetors:
Set-ReceiveConnector <ConnectorIdentity> -Banner "<220 RemainingBannerText>"
např.:
Set-ReceiveConnector "Z Internetu" -Banner "220 Mail server Firma s.r.o."

Certifikáty
Vydání certifikátů pro Exchange je dalším důležitým krokem, protože budete chtít zabezpečit webový a SMTP přístup k Exchange. Nejtěží je zvolit ta správná jména pro certifikát. Pěkný návod napsal Marin Henč na blogu TechNetu: Vygenerování jednoho SSL certifikátu pro několik jmen - http://blogs.technet.com/technetczsk/archive/2006/10/19/exchange-2007-tip-2-vygenerov-n-jednoho-ssl-certifik-tu-pro-n-kolik-jmen.aspx

nebo také zde: Creating a Certificate or Certificate Request for TLS
http://technet.microsoft.com/en-us/library/aa998840(EXCHG.80).aspx

Jen doplním, že ke cmdletu New-ExchangeCertificate můžete přidat i parametr -PrivateKeyExportable $true pro exportovatelnost privátního klíče (potřebujete-li to).

Jinak nezapomeňte i na certifikát pro SMTP, zvláště pokud upravíte zprávu pro HELO (EHLO) - nastavuje se v příslušném Receive Connectoru, protože většinou totiž nechcete zveřejňovat lokální jméno vašeho serveru. Jakmile změníte ale jméno pro HELO a EHLO, tak se vám pravděpodobně v Event Logu objeví chyba 12014.
Řešením je tedy vygenerovat certifikát pro SMTP se správným subject name: How to Troubleshoot STARTTLS Certificate Error 12014 - http://technet.microsoft.com/en-us/library/bb510128(EXCHG.80).aspx

Tím jsem se dostal do nějakých konfiguračních nastavení a tom zase třeba někdy jindy. Na závěr malá rada na statistiky:

Statistiky
Také vám chybí statistiky mailboxů v grafické konzoli, které byly v System Manager v Exchange 2003? Mně ano, ale na druhou stranu musím uznat, že možnost generovat si vlastní podle různých parametrů rozhodně také není k zahození. Nicméně pokud nevíte jak si vypsat "ty staré", tady setřídit si mailboxy nebo veřejné složky podle počtu položek v nich uložených nebo podle velikosti, zde jsou cmdlety:

Get-Mailbox -Database "Mailbox Database" | Get-MailboxStatistics | select DisplayName,TotalItemSize | sort TotalItemSize | more

Get-Mailbox -Database "Mailbox Database" | Get-MailboxStatistics | select DisplayName,ItemCount | sort ItemCount | more

Get-PublicFolderStatistics -Server <jméno vašeho mail serveru> | select Name,FolderPath,ItemCount | sort ItemCount | more

Get-PublicFolderStatistics -Server <jméno vašeho mail serveru> | select Name,FolderPath,TotalItemSize | sort TotalItemSize | more

Publikování klientského přístupu k Exchange Server 2007 přes ISA Server 2006

Jiří Hýzler — Mon, 28 Jan 2008 19:54:19 GMT

Pokud řešíte jak elegantně publikovat klientský přístup k vašemu Exchange Serveru 2007 přes ISA Server 2006, mohli by se vám hodit následující návody, zvláště pokud chcete zpřístupnit nejen Outlook Web Access (OWA), ale i Outlook Anywhere (dříve RPC over HTTPS), UM, ActiveSync a hlavně vynikající technologii Autodiscover pomocí jediného pravidla buď se dvěma nebo dokonce s jedním ISA listenerem!

Zde je návod pro 2 listenery: http://www.isaserver.org/tutorials/web-listeners-web-publishing-rules.html

A zde návod pro jeden listener pro všechny výše uvedené služby s využitím možnosti přemapovat pomící SRV záznamu v DNS jméno autodiscover.vaše_doména (viz KB 940881: http://support.microsoft.com/?kbid=940881 ): http://www.isaserver.org/tutorials/Publishing-Exchange-2007-Outlook-Autodiscover-2006-ISA-Firewalls.html (chybějící virtuální adresář pro ActiveSync si snadno doplníte, funguje to i pro něj)

Díky Thomasi, díky za návod.

Microsoft Active Directory Topology Diagrammer

Jiří Hýzler — Thu, 08 Nov 2007 14:05:39 GMT

Nedávno se objevil na stránkách Microsoft zajímavý nástroj pro střední a větší organizace a firmy - Microsoft Active Directory Topology Diagrammer. Tento nástroj automaticky vygeneruje Visio diagram vaší topologie Active Directory a Exchange 200x serverů. Diagramy mohou zahrnovat domény, sites, servery, administrativní a směrovací skupiny z Exchange organizace včetně konektorů.

Podmínkou je mít nainstalované Microsoft Visio 2003 nebo 2007, .NET Framework 2.0. a operační systém Windows 2000 a novější. Lze spustit i na stanici.

Nástroj si můžete stáhnout zde: http://www.microsoft.com/downloads/details.aspx?FamilyID=cb42fc06-50c7-47ed-a65c-862661742764&DisplayLang=en.

Zmenšování a rozšiřování oddílů na disku ve Vistě

Jiří Hýzler — Thu, 08 Nov 2007 09:29:31 GMT

Windows Vista a Windows Server 2008 nabízí možnost zmenšit nebo zvětšit oddíly na disku pomocí Disk Management konzole (je součástí Computer Managementu nebo jako samostatný snap-in do mmc). "Oříznout" partition na basic disku nebo simple volume na dynamic disku můžete ale jen o volné místo na konci oddílu. To znamená, že pokud máte fyzicky uloženy na konci oddílu nějaké soubory, zmenšit se vám to o moc velké místo nepodaří. Proto je dobré před zmenšením oddílu provést jeho defragmentaci a mít tak možnost zmenšit partition o větší kus.
V grafické konzoli zmenšení provedete jednoduše přes pravé tlačítko na oddílu a zvolte Shrink volume a nastavte velikost místa, o kterou chcete oddíl zmenšit.

Přes řádkové rozhraní to můžete provést přes nástroj diskpart.exe, např.:

DISKPART> select disk 0
Disk 0 is now the selected disk.

DISKPART> select part 1
Partition 1 is now the selected partition.

DISKPART> shrink querymax
The maximum number of reclaimable bytes is: 16GB

Výše uvedeným příkazem zjistíte maximum místa, o které je možné zmenšit oddíl.

DISKPART> shrink
DiskPart successfully shrunk the volume by: 16GB

Vlastním příkazem shrink provedete zmenšení. Bez parametru provede změnšení o maximální možnou hodnotu. Můžete také použít parametr minimum, kterým specifikujete o jak velké místo (v MB) si přejete zmenšit oddíl, např.:

DISKPART> shrink minimum=20000
The specified shrink size is too large.

Pokud to nepůjde zmenšit o takové místo, diskpart vás upozorní a operaci neprovede. Můžete také stanovit maximální hodnotu, o kterou se může diskpart pokusit zmenšit oddíl a pokud to nepůjde, tak o menší část až po stanovené minimum, které pokud nebude možné docílit, operace se neprovede, např.:

DISKPART> shrink desired=5000 minimum=2000
DiskPart successfully shrunk the volume by: 3000MB

Zde se pokusí zmenšit oddíl o 5GB, pokud to nepůjde, tak alespoň o takovou hodnotu, která je větší než 2GB. Pokud není možné zmenšit oddíl alespoň o 2GB, operace se neprovede.

Podobně budete postupovat, pokud budete potřebovat rozšířit oddíl o volné místo na disku. Rozšiřovat můžete partitions i simple volumes o volné místo před i za oddílem, ale pamatujte, že u partition na basic disku můžete rozšířit oddíl jen o místo bezprostředně za oddílem. Rozšiřování oddílu o místo před oddílem, stejně tak i o místo, které se nenachází bezprostředně za oddílem nebo o volné místo na druhém disku (spanned volume), můžete jen na simple volume na dynamic disku.

Jak poznat, které účty počítačů nemají změněné heslo v AD delší dobu?

Jiří Hýzler — Mon, 22 Oct 2007 13:08:48 GMT

Po přidání počítače W2k a novějšího do domény,je vytvořen účet počítače a je nastaveno heslo pro tento účet, které si automaticky počítač mění každých 30 dní (NT4.0 si měnily heslo u účtu počítače každých 7 dní). Jestliže heslo počítače není změněno během 60 dní od poslední změny hesla (např. počítač je offline), tak počítač není schopen se autentizovat do domény a musíte heslo resetovat (přes pravé tlačítko na účtě v AD).
Můžete jednoduše vyhledat účty počítačů, které si více jak 60 dní nezměnily heslo (jsou označeny jako "stale) použitím řádkového příkazu dsquery:

C:\dsquery computer -stalepwd 60

"CN=PC6,CN=computers,DC=firma,DC=cz"
"CN=WNOVAK,CN=computers,DC=firma,DC=cz"
"CN=NOTEBOOK3,CN=computers,DC=firma,DC=cz"
"CN=WM03,CN=computers,DC=firma,DC=cz"
"CN=TESTPC,CN=computers,DC=firma,DC=cz"

Tento výstup ukazuje, že 5 počítačů si nezměnilo heslo více jak 60 dní a můžete třeba zvážit, zda se nejedná o nějaké "historické" stroje a zda je ještě nutné je ponechávat v doméně.
jh