Category Archives: Windows Server

MsDeploy s NTLM zabezpečením

Nasazuji aplikace pomocí WDP na server (Windows Server 2008). Pokud msdeploy.exe předám v argumentech authType=basic a dále username a password, které používám pro přihlášení, vše funguje. Tím mám ověřeno, že můj účet má oprávnění, existuje website, atp. Nechci však psát své heslo a rád bych využil integrovaného zabezpečení.

Proto z příkazové řádky vynechávám username i password a nastavuji authType=ntlm. Pokus o nasazení aplikace se nedaří, jsem odmítnut (unauthorized).

Po drobném bádání dohledávám, že Windows autentizace je pro službu wmsvc standardně vypnutá a musí se zapnout v registrech: Pod HKEY_LOCAL_MACHINE\Software\Microsoft\WebManagement\Server je potřeba vložit DWORD klíč WindowsAuthenticationEnabled s hodnotou 1. A restartovat službu wmsvc.

Poté je již možné se k serveru připojit s využitím NTLM.

 

Automatické ukončování odpojených RDP session po určité době

Na Terminal Services lze nastavit, aby se odpojené (disconnected) session automaticky ukončily:

  1. Control Panel ~ Administrative Tools
    ~ Terminal Services ~ Terminal Services Configuration (do Windows Server 2008).
    ~ Remote Desktop Services ~ Remote Desktop Session Host Configuration (od Windows Server 2008 R2)
  2. Right-Click na RDP-Tcp + Properties (nebo double-click, je to default akce).
  3. Záložka Session, volba End a disconnected session:image

Pozor, že se jedná opravdu o tvrdé nevybírané ukončení session, takže se to nebude mazat s žádnou neuloženou rozpracovanou úlohou, běžícím Profilerem/Debuggerem/Fiddlerem nebo čímkoliv podobným.

HTTP Redirect nastavovaný z IIS Manageru umí zavařit

Dneska ráno nás v práci uvítal critical ticket v HelpDesku, jednomu ze zákazníků „nešel web a všechno, co po přihlášení zkusil, vedlo na homepage“. Hned se nám spojilo, že to je web, na který kolega nastavoval přesměrování HTTP requestů na HTTPS a zkoušel si různé způsoby, jak to udělat.

Jeden z testů, které udělal, byl přes <httpRedirect> (HTTP Redirection). Pak od něj ale upustil a redirect nastavený přes IIS Manager zase vypnul.

Souhra okolností chtěla, aby toto zapnutí a vypnutí způsobilo poměrně velký problém.

Po IIS Manageru zůstalo v hlavním ~/web.configu webu toto:

<system.webServer>
		<httpRedirect enabled="false" destination="https://chester.xerox.cz" httpResponseStatus="Permanent" />
</system.webServer>

To by samo o sobě nevadilo. Peklo však nastalo v okamžiku, kdy se to potkalo s web.config soubory v podsložkách, v nichž byla různá specifická přesměrování od vývojářů:

<system.webServer>
		<httpRedirect enabled="true" exactDestination="true">
			<add wildcard="/Old-URL.aspx" destination="New-URL.aspx"/>
			...
		</httpRedirect>
</system.webServer>

Když se to celé sečetlo, tak ve všech takových podsložkách se reaktivoval disablovaný redirect z rootového web.configu a veškeré requesty na resources v dané složce přesměrovával.

…další důvod proč nemám rád, když IIS Manager modifikuje web.config. Hlavním je ten, že při nasazování chci web.config přepisovat vždy celý novou verzí a jakékoliv production-specific volby z něj mít vyextrahovány třeba pomocí atributu configSource.

Chyba 404 při přístupu na ASP.NET aplikaci v Classic managed pipeline modu na II7

Symptom

Pokud přepneme application pool do Classic managed pipeline mode a dostáváme podivnou chybu 404, jedná se velmi pravděpodobně o chybu

HTTP Error 404.2 - Not Found
The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.
Error Code 0x800704ec

Tuto podrobnější chybu se můžeme dozvědět, pokud přístup uděláme přímo ze browseru běžícím na serveru (což bohužel ne vždy lze, viz třeba problémy s lokální integrovanou authentizací).

Cause

Každopádně problém je v tom, že nejsou v nastavení IIS povoleny ISAPI extenze pro ASP.NET 4.0.

Action

  1. IIS Manager
  2. server level
  3. ISAPI and CGI restrictions
  4. u zakázaných ASP.NET 4.0 extenzí, které potřebujeme, nastavit Allow

Task Scheduler – dvojí Stop task if it runs longer than…

Pozor na Task Scheduler, pokud mu nastavujete limit „Stop task if it runs longer than“. Ten limit je tam totiž dvakrát, a už jsem se několikrát napálil, že na jednom místě byl nastaven dostatečný a z druhého místa mi to task sestřelovalo a nedobíhal:

  1. Prvním místem je záložka „Settings“ v dialogu vlastností tasku.
  2. Druhým místem jsou Advanced Settings v editaci nastavení Triggeru tasku (Pro každý trigger jde nastavit limit jiný, což je sice hezké, ale…)

IIS: Jaký w3wp.exe patří k jakému AppPoolu?

Na IIS6 existoval ve složce System32\ jednoduchý skript k vypsání seznamu worker-procesů a jejich příslušnosti k jednotlivým application poolům IIS:

iisapp.vbs

Na IIS7 už tento skript není, ekvivaltentní příkaz z System32\inetsrv\ však je

appcmd list wp

image

Pozor na IIS Application pool: Maximum Worker Processes (Web Garden)

V nastavení application poolu na IIS je zastrčeno jedno nastavení s výchozí hodnotou 1, které je poměrně zrádné, pokud ho někdo změní a neví, co to přesně znamená.

Jde o volbu „Maximum Worker Processes“ a neznalé svádí tuto hodnotu z jedničky zvětšit na vyšší číslo.

Co to však ve skutečnosti znamená – jde o to, že IIS pustí pro Application Pool více instancí Worker Processu (w3wp.exe), které jsou navzájem izolované. Vznikne tak více nezávislých instancí aplikací běžících na daném Application Poolu a celé se to začne chovat jako Web Garden (= lokální virtuální Web Farm na jednom serveru). Následky jsou pak prakticky stejné, jako běh aplikace na webové famě – instance aplikace mezi sebou nezdílí kontext (Application, Cache, in-proc Session, atp.).

Protože každý Váš request pak může vyřdit jiná instance aplikace, projevy mohou být např. následující:

  • ztrácí se Vám Session, pokud používáte výchozí InProc session (hodnoty Session jsou uloženy na jiném „serveru“, než který vyřizuje aktuální request),
  • nefunguje dobře cachování (každý „server“ si udržuje vlastní cache a musí se tedy naplnit tolik cachí, kolik „serverů“ Vám běží),
  • ztrácí se Vám hodnoty Application contextu (opět stejný důvod),
  • nefungují Vám grafy DevXpress (protože si obrázek ukládají do lokálního contextu v okamžiku renderování stránky s grafem a požadavek browseru na obrázek grafu se dostane na jiný „server“),
  • atp. atp.

Osobně v běžném provozu nenacházím scénář, kde by Maximum Worker Processes mělo být nastaveno jinak než na 1. Dokážu si představit jedině, že někdo chce záměrně testovat chování své aplikace na webové farmě, nebo nějaké obskurní důvody s unmanaged componentami, nebo řešením nedostatečné thread-safety aplikace.