Category Archives: IT Stuff

GoogleToolbarNotifier.exe – součást Google Toolbar 4

Zanechat odpověď

Zaktualizoval se mi Google Toolbar, nu což, dobrá. Do programů spouštěných při startu Windows mi však přibyl GoogleToolbarNotifier.exe. A nejenom, že tam přibyl, i si chtěl hned komunikovat ven kamsi na port 80 (HTTP, možná CLR). O to se Tě Google opravdu nikdo neprosí!!!

Údajně to má být utilitka, která si hlídá, aby v IE nedošlo ke změně výchozího vyhledávače na něco jiného.

Každopádně konvenčně lze spouštění tohoto procesu vypnout v Options Google Toolbaru, na záložce More vypnout „Notify me on settings change“ a „Set and keep Seach settings to Google“. Tím dojde k odstranění spouštěcího klíče z registru (HKCU\Software\Microsoft\Windows\CurrentVersion\Run).

NTBACKUP: Scheduled job failuje – médium není prázdné

Zanechat odpověď

Pokud vytvoříme pomocí wizzardu full backup job zálohování na médium – schedulovanej na každý den – a předpokládáme, že budeme prostě jen cyklicky měnit média – tak nám po prvním cyklu zálohy přestanou probíhat, po chvilce pátrání se dostaneme k chybové hlášce „médium není prázdné“.

V základním nastavení ntbackup totiž média nemaže, což lze považovat za rozumné výchozí nastavení, nicméně pro náš případ nevhodné. Pokud bychom to neměli jako scheduled task, aplikace by se nás na smazání zeptala, nicméně takto job sfailuje.

Řešením je přidání parametru /UM do příkazové řádky, kterou příslušný scheduled task provádí. Tím se vynutí smazání média před spuštěním zálohování.

Windows 2000 Server: Event ID 1202, SceCli, 0xd : The data is invalid.

Zanechat odpověď

Tento warning se nám může množit v Application event logu, po aplikaci šablony zabezpečení Basicdc.inf. Potíž je v tom, že se tato šablona odkazuje na proměnné %SYSVOL%, %DSDIT% a %DSLOG“, které však neexistují (existují jen během Dcpromo procesu).

Stačí tedy tyto environment variables vytvořit. Výchozí složky jsou následující

%SYSVOL% = C:\WINNT\SYSVOL
%DSDIT% = C:\WINNT\NTDS
%DSLOG% = C:\WINNT\NTDS

…a warning je pryč.

IIS6: Volba výchozích regionálních nastavení pro ASP stránky

Zanechat odpověď

Můžeme se dočkat nepříjemností, pokud v ASP stránkách spoléháme na konkrétní regional-settings. Přesuneme-li aplikaci na server jiné lokalizace, nepomůže nám totiž ani nastavení Control Panel ~ Regional Settings (Ovládací panely ~ Regionální nastavení).

Je v podstatě několik možností, jak správný region vnutit, nicméně na IIS5.1+ mi jako nejlepší přijdezměna hodnoty AspLCID v IIS metabázi:

\\LM\W3SVC\AspLCID

Pro české regionální nastavení je správná hodnota 1029, hodnoty ostatních uvádí Microsoftí List of Locale ID (LCID).

Související zdroje informací:

msdtc -resetlog řeší 99% problémů s Distributed Transaction Coordinatorem (MS DTC)

Zanechat odpověď

Pokud nejde spustit služba Distributed Transaction Coordinator (MS DTC), bez které ostatně nefunguje skoro nic pořádně, pak mi osobně v 99% případech pomůže jednoduchý fígl z příkazové řádky

msdtc -resetlog

…jak je již zřejmé, vyresetuje se tím log MS DTC (což mj. zlikviduje všechny pending transakce). Problém je obvykle vyřešen.

Ostatně jedna z nepříjemných hlášek IIS „Server Application Error“, kdy je v event logu cosi ve smyslu „The server failed to load application ‚/LM/W3SVC/1/ROOT‘. The error was ‚Class not registered‘.“ se řeší právě takto.

adprep na Windows 2003 Server R2

Zanechat odpověď

Ve všech postupech Microsoftu je krásně popsáno, jak se má použít utilita adprep pro přípravu Active Directory na Windows 2000 Serveru pro použití s Windows 2003 Serverem (ať už před upgrade nebo před prostým přidáním dalšího DC).

Všechny návody však jaksi pomíjí, že na disku 2 Windows 2003 Serveru R2 je nová verze této utility a pokud použijeme tu z disku 1, o které všechny návody píšou, tak DC nepřidáme…

Intel Matrix Storage Manager instalace: File copying was not successful

Zanechat odpověď

Při snaze instalovat Intel Matrix Storage Manager (6.0 i 5.7) anglickou verzi na Windows 2003 Server R2 anglický s českým regionálním nastavením a českým nastavením „Language for non-Unicode programs“ instalátor vždy skončil na hlášce

File copying was not successful.

FileMonem jsem zjistil, že se instalátor pokouší číst soubory, které v instalační složce nejsou, přičemž problém bude zřejmě s jazykovou mutací. Zkusil jsem tedy stáhnout a instalovat z Multi-language instalátoru a vše šlo – až na to, že mi nutil češtinu.

Nakonec jsem český MSM odinstaloval, přepnul volbu „Language for non-Unicode programs“ na English a pak už fungoval i anglický instalátor.

FTP: Nastavení práv na složku pro příchozí soubory – /incoming

Zanechat odpověď

Poměrně často dostávám dotaz, jak nastavit práva na FTP složku pro příchozí soubory – složku /incoming (i když já doporučuji jiný název, viz dále).

V podstatě chceme dosáhnout toho, aby anonymní uživatel:

  • mohl do složky libovolně přidávat soubory,
  • mohl zobrazovat seznam souborů ve složce – chceme mu dát možnost, aby si ověřil, že jeho soubor byl úspěšně nahrán,
  • nemohl ze složky soubory mazat – nechceme přeci, aby nám kdokoli mohl smazat soubory určené pro nás,
  • nemohl ze složky číst – nejenom, že nechceme, aby nám někdo cizí mohl číst soubory určené pro nás, ale navíc bychom si povolením čtení připravili hodně krušné chvíle – roboti totiž pravidelně procházejí FTP servery a přímo vyhledávají takovéto složky, kde je povolen zápis a čtení – v případě úspěchu se velmi rychle stanete uložištěm pro warez, videa a jiné nechtěné soubory.

Právě z posledního uvedeného důvodu, kdy se roboti zaměřují převážně na složku /incoming a ostatní složky pro zrychlení ignorují, doporučuji pojmenovat složku pro příchozí soubory jinak. V českém prostředí například /prichozi.

A teď jak na práva:

  • práva budeme nastavovat účtu anonymního uživatele (obvykle IUSR_SERVER),
  • práva aplikujeme přímo na složku pro příchozí soubory – /incoming, /prichozi,
  • nevystačíme si se standardní záložkou Vlastnosti ~ Zabezpečení, ale musíme dát „Upřesnit“,
  • vytvoříme pro anonymního uživatele pravidlo, kde Použít pro nastavíme na Tato složka a podsložky (standardně je to totiž Tato složka, podsložky a soubory) apovolíme vše mimo
    • Full Control – Úplné řízení,
    • Delete Subfolders and Files – Odstraňovat podsložky a soubory,
    • Delete – Odstraňovat,
    • Change Permissions – Měnit oprávnění
    • a Take Ownership – Přebírat vlastnictví.
  • ještě můžeme zvážit práva Zapisovat atributy, popř. Zapisovat rozšířené atributy, ale to už celkem není nic proti ničemu.
  • musíme si dát také pozor, jestli se nám z nadřazené složky nedědí nějaká další práva, ale nebývá to obvyklé (spíše by se dalo považovat za chybu, kdyby anonymní uživatel měl na kořenovou složku FTP serveru nějaká práva, která by se dědila na podsložky).

Tím, že pravidlo aplikujeme pouze na objekty typu složka, nikoliv na soubory, dosáhneme právě toho, že uživatel sice všechno uvidí, ale nebude moct číst jednotlivé soubory.

Také si dejte pozor, jestli Vám nevznikají práva k souborům nějakým jiným děděním, klasickou chybou jsou třeba práva pro CREATOR OWNER.

Připojení Outlooku RPC over HTTP(S) na Exchange

Zanechat odpověď

Na netu jsou stovky návodů, jak nakonfigurovat RPC over HTTP komunikaci Outlooku s Exchange serverem, např.

Návody jsou to celkem srozumitelné, nicméně může nastat mnoho zásadních zádrhelů, které návody nedostatečně zmiňují, či málo zdůrazňují. Některé, na které jsem narazil já:

Certifikát k HTTPS spojení musí být důvěryhodný

Pokud používáme k HTTPS certifikát generovaný vlastní certifikační autoritou (CA), pak musíme na klientském počítači zajistit, aby připojení k serveru probíhalo čistě, bez jakéhokoliv promptu Internet Exploreru na certifikát. Outlook totiž tento prompt nepodporuje a spojení zamítne.

V podstatě je potřeba nainstalovat certifikát na klienta, třeba přístupem na https://server/rpc/rpcproxy.dll. Musíme dosáhnout stavu, aby se nás to ptalo jen na heslo, na nic jiného. Nainstalovaný certifikát nám však bude fungovat jen v případě, že máme instalovaný i certifikát CA – ten je v členských počítačích domény instalován automaticky (pokud CA používá AD), na nečlenských počítačích je potřeba ho instalovat samostatně.

Pozor – narazil jsem na problém, kdy IIS mělo přidělený certifikát, ale mezi tím došlo k reinstalaci CA. Certifikát na IIS tak neodpovídal kořenovému certifikát CA. Internet Explorer to navíc pojal po svém. Místo, aby ohlásil neplatný certifikát, tak po instalaci kořenového certifikátu na jakýkoliv HTTPS požadavek vůči příslušnému serveru odpovídal chybou „Server nebyl nalezen nebo došlo k chybě v systému DNS.“ (jako kdyby server neexistoval).

Global Catalog na jiném serveru

Pokud máme scénář s jedním Exchange serverem, na kterém navíc běží i doménový řadič (DC), může se zdát, že není co řešit. Zásadní komplikace však nastane, pokud máme v doméně více DC a Global Catalog je na jiném serveru, než Exchange.

Který server je Global Catalogem poznáme v konzoli Active Directory Sites and Services, pokud si nalistujeme příslušný server, položku „NTDS Settings“ a k ní Properties – tam je zaškrtávací políčko Global Catalog. Jak přesunout GC na jiný server je mimo dosah tohoto článku.

Pokud tedy máme GC na jiném serveru, nestačí nám standardní konfigurace portů (hodnota ValidPorts), protože potřebujem na port 6004 dostat právě process lsass.exe z GC.

Jedna možnost je přesunout GC na stejný server k Exchange. Druhou možností je nastavit klíč registru „NSPI interface protocol sequences“ i na GC server a na exchange serveru nastavit v klíči „ValidPorts“ port 6004 na GC server (NetBIOS jméno i FQDN). V Outlooku pak jako server exchange vyplníme NetBIOS název GC serveru.

Pozor na to, že nám ve standardním nastavení funguje dokonce i RPCPING, protože si server s exchange na port 6004 nasadí vlastní proces lsass.exe. Nicméně Outlook zahájí komunikaci a nic se nepřipojí. V logu webové služby jsou též korektní řádky RPC_IN_DATA a RPC_OUT_DATA se success kódem 200.

Troubleshooting nástroje a doporučení

  • spouštět Outlook s parametrem outlook /rpcdiag (též Ctrl+RClick na tray-ikonu Outlooku a volba Connection Status…)
  • telnet localhost 6001,  6002, 6004 (ze serveru) dává banner „ncacn_http/1.0“
  • netstat -ano (ze serveru) nám říká, jaké procesy obsluhují jaký portu (6001-store.exe, 6002-mad.exe, 6004-lsass.exe nebo mad.exe),
  • utilita rpcping z Windows Server Resource Kitu (z klienta),
  • utilita rpcdump z Windows Server Resource Kitu (z klienta i ze serveru),
  • adresa https://server/rpc/ se musí ptát na heslo a pak odpovědět 401.3,
  • adresa https://server/rpc/rpcproxy.dll se musí ptát na heslo a pak odpovědět prázdnotou,
  • v logu webové služby musí být záznamy RPC_IN_DATA a RPC_OUT_DATA, kód 200.
  • při nastavování accountu v Outlooku musí být v základním dialogu interní jméno serveru a až v nastavení RPC over HTTPS se dávají public jména serveru (ty se musí shodovat se jménem, na které je vystaven certifikát pro SSL)

VPN přípojení a zachování přístupu k internetu

Zanechat odpověď

Pokud používáme VPN klienta z Windows a připojujeme se k virtuální privátní síti (VPN), pak ve výchozím nastavení ztratíme po připojení k VPN přímý přístup k internetu, protože VPN klient nastaví default gateway na vzdálenou default gateway VPN serveru (i z důvodu zabezpečení VPN). Veškerá IP komunikace, která není explicitně routována jinak (což obvykle není), je tak směřována na default gateway VPN připojení – to buď požadavek vyřídí, nebo nevyřídí (často právě spíše nevyřídí a „jsme bez internetu“).

Každopádně, pokud chceme zachovat dosavadní gateway, stačí ve vlastnostech VPN připojení odškrnout položku „Use default gateway on remote network“, respektive„Používat výchozí bránu vzdálené sítě“. Tu najdeme na záložce Sítě, pod vlastnostmi protokolu TCP/IP a Upřesnit, ve starých Win9x to bylo pod Properties ~ Server Types ~ TCP/IP Settings.

Pozor však, že standardní volba má svojí logiku. Pokud se připojíme na VPN, stává se náš počítač rozhraním mezi firemní sítí a internetem a je tak potenciálně nebezpečným místem pro útoky.