Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Správa automatického spouštění aplikací PowerShellem

Written by administrator

Všichni čas od času řešíme, co se nám spouští spolu s přihlášením, no startem systému. Často jsou to chtěné funkcionality, jako třeba OneDrive, ale např. Teams již chtěné být nemusí a spousta dalších aplikací zrovna tak. Běžně se tyto problémy dají řešit pomocí Autoruns od Sysinternals, správcem úloh, nebo složitěji přes registry, služby a specifické složky. Ale jak to řešit na vzdáleném počítači? Když vynecháme RDP, AnyDesk a další, které připojí pracovní plochu jiného PC, zbyde nám PowerShell a editor registru (pokud je povolná vzdálená správa registru). A právě o možnostech PowerShellu to dnes bude.

PowerShllem máme 2 možnosti řešení, tu komplexnější, kdy využijeme vzdáleného připojení pomocí Enter-PSSession -ComputerName <název počítače>, nebo budeme využívat parametr ComputerName. Níže budu popisovat řešení přímé připojení se k danému stroji pomocí Enter-PSSession.

Automaticky spouštěné položky vypíšeme následujícím příkazem:

Get-CimInstance Win32_StartupCommand | Select-Object Name, command, Location, User | Format-List

Bližší informace k příkazu Get-CimInstance jsou v dokumentaci. Příkaz Get-CimInstance podporuje parametr ComputerName. Pokud ve výstupu bude uvedeno jako Location: common startup location, jde o cestu: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Většina položek ovšem povede do registrů. Pro práci s registry se nám budou hodit následující příkazy:

  • Get-ItemProperty -Path <doplň>
  • Remove-ItemProperty -Path <doplň> -Name <doplň>

Pokud naopak budeme chtít něco do autoranu přidat, např. Outlook, tak do registrového klíče doplníme záznam příkazem: New-ItemProperty -Path <doplň> -Name <doplň> -PropertyType <doplň> -Value <doplň>

Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Validace a oprava systémových souborů offline

Written by administrator

Dostat se do situace, že počítač nestartuje a je potřeba systém opravit pomocí WinRE nebo instalačního média zase není nic vzácného. Opravu spouštěcích souborů už Microsoft předpřipravil jako jedno kliknutí, byť stále ji můžeme provést pomocí příkazové řádky, ale stavy jako je nestartující systém po BSOD z důvodu selhání NTFS.sys neřeší a určitě i v dalších scénářích nemusí postačovat.

Možnosti kontroly jako je chkdsk nebo diskpart nejsou nikomu cizí, ale jak zkontrolovat systémové soubory offline kopie Windows, nebo offline odebrat problémový ovladač, je předmětem tohoto článku. Pro kontrolu a opravu systémových souborů slouží 2 nástroje, SFC a DISM. SFC(system file chacker) je nástroj přímo určený na kontrolu systémových souborů, a pokud chci kontrolovat a opravit offline kopii systému, zapisuji příkaz takto:

sfc /scannow /offbootdir=c:\ /offwindir=c:\windows

Písmenu systémového disku offline kopie Windows, víše C, si zjistím pomocí nástroje diskpart příkazem list volume. Další systémové komponenty je potřeba kontrolovat pomocí DISM, kdy analýzu provedeme příkazem:

Dism /Image:C:\ /Cleanup-Image /scanhealth

Následnou opravu pak:

Dism /Image:C:\ /Cleanup-Image /RestoreHealth

Písmeno disku, víše C, opět pochází z výsledku diskpartu.

Pokud je příčinou pádu systému ovladač (a není to zrovna ntfs.sys, či jiný od MS, ty opraví příkazy výše), tak je možné jej offline odebrat, následně spustit systém a danému zařízení nainstalovat ovladač nový. K zobrazení přesného názvu ovladače využijeme příkaz:

Dism /Image:C:\ /Get-Drivers /format:table

Po nalezení odpovídajícího ovladače jej odebereme pomocí příkazu:

Dism /Image:C:\ /Remove-Driver /Driver:OEM1.inf

V příkladu výše pak OEM.inf je název problémového ovladače, který jsme si našli v tabulce z předešlého příkazu.

Poslední, co se nechá se systémem, krom modifikace registrů a souborů, dělat, je vrácení změn rolí a funkcí, případně aktualizací. Na odebrání posledních aktualizací MS opět nabízí GUI, ale to neřeší případ, že k pádu OS dojde při spouštění v rámci aktualizačního restartu. Stejně tak přidávání či odebírání komponent (jako např. Hyper-V). V těchto případech se pak pomocí DISM vrátí čekající změny příkazem:

DISM /image:C:\ /cleanup-image /revertpendingactions
Posted in: Windows server

Manuální odebrání certifikační autority v AD

Written by administrator

Dnes se chci podělit o postup odebrání certifikační autority v existující doméně, když z nějakého důvodu zkolabuje a nelze obnovit (poškození OS a zálohy). Pokud je to jen trochu možné, odebírejte certifikační autoritu dle pokynů MS (viz dokumentace). Níže uvedený postup je opravdu riskantní, protože můžete poškodit jinou certifikační autoritu v doméně, doporučil bych jej ve chvíli, kdy zkolabovaná autorita byla jedinou autoritou provést dříve, nežli do domény nasadíte novou autoritu.

Praktický celý postup zvládneme v konzoli Active Directory Sites and Services, kde je potřeba mít zobrazené služby.

Pro práci budeme potřebovat větev Services\Public Key Services, kde se budeme pohybovat. S mazáním začneme ve větvi AIA uvnitř Public Key Services, kde najdeme objekt autority, kterou chceme smazat, klikneme na něj pravým tlačítkem a dáme Delete.

Nyní se přesuneme do větve CDP, kde najdeme kontejner odpovídající autority a celý jej smažeme.

Dále pokračujeme ve větvi Certification Authorities, kde smažeme objekt odpovídající autority. Pokud je odebíraná autorita podřízenou autoritou, je potřeba ověřit všechny vazby před smazáním objektu.

Dalším krokem je smazání objektu dané certifikační autority ve větvi KRA.

Posledním bodem práce v této konzoli je pak odebrání objektu autority v Enrollment Service.

Definitivní tečkou je pak odebrání autority v atributu domény, které již provedeme pomocí PowerShellu. Na tento příkaz již potřebujete oprávnění Enterprise admina.

$doma="<zadej název domény před tečkou>"
$top="<zadej název domény za tečkou>"
certutil -viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=$domena,DC=$top?cACertificate?base?objectclass=certificationAuthority"

V příkazu certutil výše přeci je doporučuji proměnné zaměnit za konkrétní hodnoty, kterých by nabývaly. Pokud Příkaz proběhne správně, zobrazí se seznam certifikátů všech certifikačních autorit v prostředí, vybereme požadovaný certifikát a potvrdíme OK.

Zdroj

Vlastní zkušenost s tímto úkonem a článek: Ruční odebrání starých odkazů na certifikační autority ve službě Active Directory | Řešení zabezpečení od Microsoftu (wordpress.com), ze kterého pochází obrázky, protože snímky z produkčního prostředí použít nemohu.

Posted in: Windows server

Přihlašovací hodiny

Written by administrator

Dnes se chci podělit o to, jak pomocí PwerShellu hromadně přenastavit, nebo vypnout přihlašovací hodny, tedy omezení, kdy se daný uživatel může v síti hlásit. Tato nastavení není v AD žádnou novinkou a důvody nastavení mohou být buď politické (požadavek vedení), nebo bezpečnostní, protože v době, kdy se uživatel nemůže hlásit, nemůže ani spouštět plánované akce a nelze jeho účet zablokovat pomocí chybného zadávání hesla. Toto nastavení by se nemělo za žádných okolností zadávat administrátorským účtům a BFÚ (obyčejným) účtům administrátorů, aby bylo možné kdykoliv reagovat na jakoukoliv situaci.

Pokud je firma s jednosměnným provozem, tak dává smysl, aby všechny zaměstnanecké (nikoliv adminské a servisní) účty byly uzamčené přes noc a pokud firma běžně pracuje od pondělí do pátku, tak také přes víkend. Toto nastavení pomůže snížit riziko kybernetického útoku, protože útočníci se snaží firmy napadat v době, kdy na ně interní IT nebude reagovat. Ve školním prostředí pak dává smysl omezit všem žákům možnost přihlášení na dobu od 7 do 16 hodin (možná 17 hodin), čímž nemusím jako admin řešit, kdo má nultou hodinu a kdo odpoledku.

Jak na to hromadně?

Začneme tím nejjednodušším a to je návrat k výchozímu stavu, tedy přihlášení povolení 24/7 všem uživatelům. Na to nám stačí jednoduchý příkaz:

#Nastavíme proměnou hours na 25/7
[byte[]]$hours = @(255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255)
Get-ADUser -Filter * | Set-ADUser -Replace @{logonhours = $hours}

Jak vyresetovat jen konkrétní OU ukáže následující příklad na OU žáci:

#Nastavíme proměnou hours na 25/7
[byte[]]$hours = @(255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255)
Get-ADUser -SearchBase "OU=Zaci,OU=Uzivatele,OU=Skola,DC=skola,DC=local" -Filter * | Set-ADUser -Replace @{logonhours = $hours}

Jak nastavit pro všechny žáky povolení přihlášení jen v pracovní dny od 7 do 16?

[byte[]]$hours = @(000,000,000,192,127,000,192,127,000,192,127,000,192,127,000,192,127,000,000,000,000)
Get-ADUser -SearchBase "OU=Zaci,OU=Uzivatele,OU=Skola,DC=skola,DC=local" -Filter * | Set-ADUser -Replace @{logonhours = $hours}

Kde vzít ono bytové pole? To je dobrá otázka, která má ve skutečnosti jednoduchou odpověď. Otevřeme si libovolného uživatele a v GUI mu nastavíme přihlašovací hodiny dle libosti, např. takto:

Když vše potvrdíme a uložíme, otevřeme znovu uživatele a podíváme do editoru atributů na atribut logonhours, který dvojklikem otevřeme a necháme si jej zobrazit dekadicky, binární příklad přidávám níže:

Tento výpis, v dekadické podobě, zkopírujeme do proměnné $hours v příkazech výše, čímž dojedeme k tomu, že dle tohoto uživatele můžeme nastavit celé OU nebo celou doménu. A proč jsem vložil binární příklad? Protože si vysvětlíme, jak to funguje.

  • 1 bit = 1 hodina
  • 3 byty (3x 8 bit) = 1 den
  • 168 bit = jeden týden

První 3 byty jsou neděle, druhé 3 byty pondělí atd. Nyní je rovněž jasné, jak vše spočítat a do příakzů výše zadávat rovnou vypočtené hodnoty 😉

Posted in: Windows server

Výpis obnovovacího klíče Bitlocker z AD

Written by administrator

Dnešní krátký kód vypíše z AD obnovovací klíč Bitlockeru, pokud je uložen v AD bez toho, aby na daném řadiči byly instalovány nástroje pro práci s Bitlockerem.

Import-module ActiveDirectory
$ADComputer = Read-Host -Prompt "Zadej jméno počítače"
$DN = Get-ADComputer $ADComputer | Select-Object -ExpandProperty DistinguishedName
$ADobj = get-adobject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} -SearchBase $DN -Properties 'msFVE-RecoveryPassword' | Select-Object Name,msFVE-RecoveryPassword
[Ordered]@{
    Computer = $ADComputer
    RecoveryPassword = $ADobj.'msFVE-RecoveryPassword'
    Date = Get-Date -Date ($ADobj.Name ).Split('{')[0]
    BitlocerKeyID = (($ADobj.Name ).Split('{')[1]).TrimEnd('}')
}
Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Oprava opakovaného vyžádání obnovovacího klíče Bitlocker

Written by administrator

Dnes jen malá poznámka o problému, se kterým se setkávám a to je, když nástroj Bitlocker si vyžádá kód pro obnovení i po správně zadaném hesle. Nejčastěji je na vině aktualizace, BIOS bez pozastavené ochrany, ale někdy i ovladačů nebo pouze systému. Níže představím rychlé řešení, které lze aplikovat z běžícího systému, nebo z WinPE po odemčení jednotky, viz starší článek.

Začne řešením pro případ, že jednotka se odemyká automaticky pomocí TPM.

manage-bde -protectors -delete C: -Type TPM
manage-bde -protectors -add c: -tpm

Případ, kdy kombinujeme TPM a PIN je obdobný, příkazy níže:

manage-bde -protectors -delete C: -Type TPMAndPIN
manage-bde -protectors -add c: -TPMAndPIN

Byť to nemusí být nezbytné, doporučuji po této operaci znovu zálohovat klíč pro obnovu. Jak tomuto stavu předcházet? Na 100% to nelze, ale nejčastěji je na vině aktualizace BIOS, proto před jejím započetím doporučuji Bitlocker pozastavit a po jejím dokončení opět obnovit ochranu.

Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Řešení problému bootrec /fixboot access deny

Written by administrator

Tento problém nastává v případě, že je potřeba opravit boot záznamy systému pro UEFI. Tento problém se týká oddílu EFI na disku využívající strukturu GPT. Podotýkám, že zde uvedený postup je až posledním řešením, často stačí příkaz chkdsk, ale pokud je potřeba provést bootre /fixboot a chybu nejde ignorovat, jde o opakovanou opravu bootu, jak jej můžete zkusit. V příkazové řádce WinRE prostředí postupujeme následovně:

  1. diskpart
  2. list vol
  3. sel vol <číslo jednotky UEFI>
  4. assign letter U
  5. exit
  6. cd /d U:\
  7. format U: /FS: FAT32
  8. bcdboot c:\windows /s U: /f UEFI
  9. cd /d u:\EFI\Microsoft\Boot\
  10. bootrec /fixboot

Často stačí skončit krokem 8, protože z adresáře systému Windows jsou do UEFI oddílu nahrány zcela nové Bootovací soubory. Když to nezabere, dokončíme všech 10 kroků.

Posted in: Windows server

Migrace FSMO rolí mezi servery

Written by administrator

K „neřízené“ migraci FSMO rolí dochází naprosto přirozeně samo, ve chvíli, kdy je nedostupný (výpadek sítě, vypnutí a pod.) server, který má nějakou FSMO roli, dočasně tuto roli převezme jiný server. Po obnovení provozu serveru, který má danou roli si je přebere zpět, ale až po úplném dokončení synchronizace.

Dnešní příspěvek je určitým českým popisem stavu, kdy je nutné FSMO roli přesunou ručně a rozhodně nenahrazuje originální dokumentaci. Sám jsem se dostal do stavu, kterému se v licenční tématice říká Permanent hardware failure, kdy jsem musel vynutit „trvalé“ převzetí všech FSMO rolí jiným serverem. Bohužel, server který selhal provozoval 4 z 5 těchto rolí. Právě o tom, jak takovéto převzetí udělat, buď v výpadku, nebo plánovat před vyřazením z provozu je tento článek. K převzetí všech FSMO rolí slouží PowerShellový příkaz:

Move-ADDirectoryServerOperationMasterRole -Identity S3 -OperationMasterRole RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator,schemaMaster -Force

Tento příkaz je potřeba spustit na serveru, který má role převzít. Parameter Identity slouží k určení cílového serveru (je povinný), ale i tak doporučuji spouštět přímo na daném serveru. Pokud chci převádět jen některé role, stačí uvést jejich výčet v parametru OperationMasterRole.

Pokud server vyřazuje z provozu plánovaně, odebírám roli DC pomocí DCpromo, respektive příkazem:

Uninstall-ADDSDomainController

V takovém případě zůstávají role automaticky „rozebrány“ dalšími kontrolery, ale je dobré se o tom ujisti.

Posted in: Windows 10, Windows 11, Windows server

Odebrání serverů ze Server management konzole

Written by administrator

Tento článek se týká Windows Serverů (verze 2012 a novější) instalované s GUI a klientských systémů Windows s instalovaným RSAT.

Konzole sama obsahuje možnost přidat servery a vytvořit skupiny serverů, do nichž je možné servery přidávat. Bohužel zde chybí možnost z této praktické konzole servery odebrat, což se ve spoustě případů může hodit. Postup odebrání je tedy následovný:

  1. příkaz: cd %userprofile%\AppData\Roaming\Microsoft\Windows\ServerManager
  2. Otevřít (k editaci, třeba Notapadem): ServerList.xml
  3. Smazat XML záznam pro server, který chceme odstranit
  4. Uložit
Posted in: Windows 10, Windows 11, Windows 8 a 8.1, Windows server

Obnova Windows z Windows.old

Written by administrator

Vrátit se k předešlé verzi systému po jeho upgrade je možné poměrně jednoduše v případě klientských Windows pomocí nastavení.

Alternativou k tomu grafickému postupu je pak příkaz:

DISM /Online /Initiate-OSUninstall /Quiet

Oba výše zmíněné postupy platí pro Windows 10 verze 2004 a novější i pro Windows 11, ale jak postupovat u Windows 8 a starších, nebo u serverových systémů?

Ruční obnova systému z Windows.old

Pro tento úkon je potřeba zařízení spustit z instalačního média systému Windows, nebo restartovat do WinRE prostředí. V případě instalačního média spustíme příkazovou řádku pomocí [Shift] + [F10], nebo pomocí volby opravit počítač, kde se nabídne prostředí WinRE. Text níže předpokládá, že i v tomto prostředí má systémový oddíl písmeno C, ověřit to můžeme nástrojem diskpart.

Začneme odstraněním adresářů nového systému (složku C:\users mažeme jen tehdy, když bylo upgradováno BEZ zachování uživatelských souborů). K mazání používáme následující sadu příkazů:

rmdir /s /q "c:\PerfLogs"
rmdir /s /q "c:\Program Files"
rmdir /s /q "c:\Program Files (x86)"
rmdir /s /q "c:\Windows"
rmdir /s /q "c:\ProgramData"
rmdir /s /q "c:\Users"

Nyní nastal čas na to, abychom přesunuli původní (v příkladu x64) systém na disk C.

move /y c:\Windows.old\Windows c:\
move /y "c:\Windows.old\Program Files" c:\
move /y "c:\Windows.old\Program Files (x86)" c:\
move /y c:\Windows.old\ProgramData c:\
move /y c:\Windows.old\Users c:\
move /y "c:\Windows.old\Documents and Settings" c:\
xcopy c:\Windows.old c: /s /e /h

V tuto chvíli máme sice na disku C vybalený zpět původní systém, ale nešlo by z něj nastartovat. Musíme ještě opravit Boot.

Oprava Boot pro UEFI

Pomocí následujících příkazů nalezneme oddíl UEFI a přidělíme mu písmeno:

diskpart
list vol

Nyní najdeme UEFI oddíl, jeho velikost je cca 100 MB a využívá formát FAT32. Jeho číslo budeme potřebovat dále.

sel vol <number of volume>
assign letter=U:
exit

Nyní již můžeme k vlastní konfiguraci Bootu pro UEFI.

cd /d U:\EFI\Microsoft\Boot\
bootrec /FixBoot
ren BCD BCD.old
bcdboot c:\Windows /s U: UEFI

Pokud nemáte systémový oddíl jako C, doplňte místo C do posledního příkazu písmeno vašeho systémového oddílu. Pokud příkaz „bootrec /FixBoot“ skončí chybou, chybu ignorujte a pokračujte v příkazech dále. Nyní můžeme restartovat systém.

Oprava Boot pro BIOS (MBR spouštění systému)

Oprava boot pro systémy, které využívají MBR (tedy BIOS) je jednoduší, stačí následující příkazy:

bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

Máme hotovo, můžeme resetovat systém.

Oprava Boot pro Windows to Go

Pomocí následujících příkazů nalezneme oddíl UEFI a přidělíme mu písmeno:

diskpart
list vol

Nyní najdeme UEFI oddíl, jeho velikost je cca 100 MB a využívá formát FAT32. Jeho číslo budeme potřebovat dále.

sel vol <number of volume>
assign letter=U:
exit

Nyní již můžeme k vlastní konfiguraci Bootu pro UEFI.

cd /d U:\EFI\Microsoft\Boot\
bootrec /FixBoot
ren BCD BCD.old
bcdboot c:\Windows /s C: All

Pokud nemáte systémový oddíl jako C, doplňte místo C do posledního příkazu písmeno vašeho systémového oddílu. Pokud příkaz „bootrec /FixBoot“ skončí chybou, chybu ignorujte a pokračujte v příkazech dále. Nyní můžeme restartovat systém.

Dokončení

Může se stát, že systém se nespustí na přihlašovací obrazovku, ale do prostředí WinRE, v tom případě se i na serverových systémech objeví možnost Oprava spouštění systému (níže ilustrační obrázek z Windows 10).

Toto již většinou bez problémů projde a systém se automatizovaně doopraví a spustí. Po přihlášení se nejspíš zobrazí chyba, že koš systémové jednotky je poškozen a je potřeba jej vysypat, zde zadejte NE. Nyní doporučuji zkontrolovat NTFS a systémové soubory pomocí sady následujících příkazů:

sfc /scannow
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /restorehealth
echo y | chkdsk c: /f
shutdown /g /t 0 /f

Při restartu dojde ke kontrole systémové jednotky C, doporučuji nechat proběhnout! Po dokončení a přihlášení je možné hlášku poškození koše potvrdit ANO pokud se ještě zobrazí. Dle mé zkušenosti se při tomto postupu u serverových systémů ztratí veškerý obsah ze start menu, což je opravdu nepříjemné, ale dobrou zprávou je, že aplikace jsou v systému a fungují.

Back to Top