IIS címkéhez tartozó bejegyzések

Ott a fájl, de mégis 404

Próbálnék betölteni egy ASPX fájlt, de sehogy nem akar sikerülni. Pontosabban IIS Expressen a forráskódot futtatva megy kiválóan, de IIS-re publisholva 404 lesz belőle.

Látszólag minden rendben van, ott van a fájl a szerveren, csak épp nem töltődik le. Bekapcsolom a Failed Request Tracinget, hátha látszik valami. Látszik bizony: 388 napló bejegyzés egyetlen HTTP kéréshez. Még szerencse, hogy van Request Summary nézet, ami rögtön kiemeli az egyetlen warningot:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName: ManagedPipelineHandler

Notification: EXECUTE_REQUEST_HANDLER

HttpStatus: 404

HttpReason: Not Found

HttpSubStatus: 0

ErrorCode: The operation completed successfully. (0x0)

Önmagában nem éppen nagy segítség, de legalább kiderült belőle, hogy melyik modul a bűnös. Kis öröm. Kikeresem a bejegyzést a Complete Request Trace-ből és megnézem, mi van előtte. AspNetParse és AspNetCompile bejegyzések. Talán valami gond van az ASPX fájllal? Nem valószínű, hiszen IIS Expressben megy, ráadásul NuGet package-ből jött.

Azért csak megnézem a forráskódot. Rögtön az első sor gyanús: a @Page direktívában CodeFile szerepel. Szokatlan. Átírom CodeBehindra. Fordítok, telepítek.

Megjavul.

Technorati-címkék: ,,

Az IIS Express mindig újraindul

A Visual Studio 2013-mal telepített IIS Express használata közben feltűnhet, hogy a korábbi verziókkal ellentétben a debuggolás végén mindig leáll a webszerver. Ez annak köszönhető, hogy a Visual Studio 2013-tól kezdve nem csak hogy van Edit and Continue támogatás 64-biten, de most már ez alapból be is van kapcsolva web alkalmazások esetén:

iis-express-edit-and-continue

Ha erre nincs szükségünk és kikapcsoljuk, akkor nem fog leállni az IIS Express.

 

Technorati-címkék: ,

Az IIS Express kitakarítása

Az IIS Express a beállításait a %USERPROFILE%\Documents\IISExpress\config\applicationHost.config fájlban tárolja, ami nagyon kényelmes, hiszen így nem szükséges rendszergazdai jog a szerkesztéséhez. Ennek következménye, hogy a Visual Studio eltávolításával a webszerver és a webalkalmazások beállításai megmaradnak.

Előfordulhat, hogy eltávolítjuk a VS 2012-t, telepítjük a 2013-as verziót, majd létrehozunk egy új webalkalmazást, ami szokatlanul viselkedik, például minden indításakor Windowsos bejelentkezést kér. Ez lehet amiatt is, hogy a korábban már hoztunk létre ugyanilyen néven webhelyet az IIS Expressben, aminek a beállításai megőrződtek a konfigurációs fájlban.

Ha a szokásos projektjeink mellett gyakran hozunk létre tesztelésre webprojekteket, akkor időnként érdemes kitakarítani az IIS Expresst. Mivel nincsen hozzá grafikus felületünk, vagy kézzel szerkesztjük az applicationHost.config fájlt, vagy parancssorból esünk neki.

Az Expresses appcmd.exe a C:\Program Files (x86)\IIS Express mappában található. Listázhatjuk vele a webhelyeket:

C:\Program Files (x86)\IIS Express>appcmd list site
SITE "WebSite1" (id:1,bindings:http/:8080:localhost,state:Unknown)
SITE "MyProject" (id:2,bindings:http/*:44441:localhost,https/*:44300:localhost,state:Unknown)
SITE "WebSite1(1)" (id:3,bindings:http/*:44468:localhost,state:Unknown)
SITE "WebSite2" (id:4,bindings:http/*:44465:localhost,state:Unknown)

Ha a webhelyek nevei nem mondanak sokat, akkor listázhatjuk a virtuális mappákat, mert azok mellett megjelennek a fizikai útvonalak is:

C:\Program Files (x86)\IIS Express>appcmd list vdir
VDIR "WebSite1/" (physicalPath:%IIS_SITES_HOME%\WebSite1)
VDIR "MyProject/" (physicalPath:W:\Projektek\MyProject)
VDIR "WebSite1(1)/" (physicalPath:W:\Temp\WebSite1)
VDIR "WebSite2/" (physicalPath:W:\Desktop\WebSite2)

Ha valamelyik webhelyre még szükségünk van, csak épp értelmes nevet akarunk neki adni, akkor átnevezhetjük:

C:\Program Files (x86)\IIS Express>appcmd set site WebSite1(1) -name:Master
SITE object "WebSite1(1)" changed

Amire pedig nincs szükség, azt bátran törölhetjük:

C:\Program Files (x86)\IIS Express>appcmd delete site WebSite2
SITE object "WebSite2" deleted

 

Technorati-címkék: ,,

Árulkodó HTTP fejlécek eltávolítása

Ha megnézzük egy ASP.NET alkalmazásunk hálózati forgalmát, akkor könnyen felfedezhetjük az alábbi fejléceket a HTTP válaszban:

Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 5.0

Ezek a fejléc mezők egyáltalán nem befolyásolják az alkalmazás működését, az egyetlen céljuk, hogy a Bing bot több információt nyerjen a webhelyről.

Sajnos azonban ezek a fejlécek a támadók dolgát jelentősen megkönnyítik, hiszen ha pontosan ismert a platform és a verziószám, akkor már elég csak azokkal az támadásokkal próbálkozni, amik ebben a környezetben működnek. Éppen ezért biztonsági okokból célszerű megváltoztatni az alapbeállításokat és eltávolítani ezeket a fejléceket.

 

Server

A Server fejléc “sugárzása” bele van drótozva az IIS-be, én nem tudok olyan kapcsolóról, amivel kényelmesen kikapcsolható lenne. Lehet használni az UrlScant, bár az az eszköz utoljára 2008-ban frissült. Ha ASP.NET alkalmazásunk van, akkor a global.asax-ban leszedhetjük ezt a fejléc mezőt, mielőtt a HTTP válasz kimenne a szerverről:

protected void Application_PreSendRequestHeaders()
{
  this.Response.Headers.Remove( "Server" ); }

 

X-Powered-By

Az X-Powered-By fejlécet az IIS pakolja rá a HTTP válaszokra, így akár szerver szinten megszabadulhatunk tőle az IIS Managerben:

header-x-powered-by

 

Vagy akár web.configban is:

<system.webServer>
   <httpProtocol>
     <customHeaders>
       <remove name="X-Powered-By" />
     </customHeaders>
   </httpProtocol>
</system.webServer>

 

X-AspNet-Version

Az X-AspNet-Version fejlécet viszonylag egyszerű kikapcsolni a web.configban:

<httpRuntime enableVersionHeader="false" />

 

X-AspNetMvc-Version

Az X-AspNet-Version fejlécet az alkalmazásunk indulásakor kapcsolhatjuk ki:

protected void Application_Start()
{
MvcHandler.DisableMvcResponseHeader = true; }

 

Ha mindezeket a beállításokat egyszerűbben szeretnénk elvégezni, akkor támaszkodhatunk a CodePlexen ingyenesen elérhető NWebsec projektre, amely a konfiguráció szigorításán kívül további lehetőségeket nyújt MVC-s és Azure-os projektek számára, illetve a session kezelés biztonságosabbá tételére. Ezek a funkciók egymástól függetlenül, önállóan is elérhetők NuGet csomagok formájában.

 

Technorati-címkék: ,,

IIS konfiguráció auditálás

Az IIS konfigurációs beállításai között nem nehéz olyat találni, aminek az átbillentése egy csapásra nem biztonságossá teszi a szervert. Éppen ezért nagyon fontos, hogy a konfiguráció változásait tudjuk követni, monitorozni. Szerencsére ez egy beépített lehetőség a webszerverben, csak nem ott kell keresni, ahol az összes többi opciót.

Indítsuk el az Event Viewert, majd navigáljunk el az Application and Services Logs –> Microsoft –> Windows –> IIS Configuration –> Operational ágig. Kattintsunk ezen az ágon jobb egérgombbal és válasszuk az Enable Log menüpontot az auditálás bekapcsolásához:

iis-config-audit-log

Ezek után minden egyes IIS módosítás megjelenik ebben a naplóban:

iis-config-audit-general

A General nézetben a módosított beállításon kívül jóformán csak a módosítás ideje és a felhasználó neve jelenik meg, de a Details nézetben több információt is találunk:

iis-config-details

Nem árt tudni, hogy csak azok a módosítások jelennek meg, amik az IIS Manageren vagy az objektum modellen keresztül történnek; ha az applicationHost.config fájlt Notepaddel szerkesztjük, annak sajnos nem lesz nyoma a naplóban.

 

Technorati-címkék: ,,,

IIS távoli felügyelete Windows 8.1-ről

Az Internet Information Services (IIS) Manager (inetmgr.exe) egyik kiváló szolgáltatása, hogy a saját gépünkön elindítva, grafikus felületen keresztül, távolról felügyelhetjük vele a webszervereinket. Ehhez nem kell mást tennünk, mint kiválasztanunk a File menüből a Connect to a Server menüpontot:

inetmgr-connect-to-file-menu

Ez végigvezet egy varázslón, és ha a szerveren telepítve van a Web Management Service, akkor pillanatok alatt csatlakozhatunk a webszerverünkhöz, webhelyünkhöz vagy webalkalmazásunkhoz.

A gond akkor van, ha nincs ilyen menüpont, márpedig nincs. Sem Windows 7-en, sem Windows 8-on, sem 8.1-en. bezzeg Save Connections van (igaz, disabled állapotban), de vajon minek?

inetmgr-default

Windows 7 esetén még történeti okokra hivatkozva talán megértem, de az újabb kliens operációs rendszerek esetén nem találok magyarázatot. Ha már mindenképp külön kell letölteni, akkor lehetne például az RSAT része.

Oldjuk meg hát a problémát, irány a Web Platform Installer, ahol például a “remote” szóra keresve pillanatok alatt megtalálhatjuk az IIS Manager for Remote Administration v1.1 verziót:

inetmgr-webpi-search

Senkit ne tévesszen meg a két évvel ez előtti dátum, pont ez kell nekünk. Bökjünk a sorban az Add, majd alul az Install gombokra, végül a következő ablakban az I Accept gombra kattintva fogadjuk el a licenc előírásait. Elindul a letöltés, megkezdődik a telepítés, majd jön a hidegzuhany:

inetmgr-webpi-sorry

Nem sikerült a telepítés, mert Windows 7 vagy újabb kell neki. De hát ez egy Windows 8.1, jaj!

Próbálkozzunk meg ismét a telepítéssel, de most a licenc elfogadása ablakban kattintsunk inkább a Direct Download Link hivatkozásra:

inetmgr-webpi-licence

Ennek hatására az alapértelmezett böngészőnk letölti a telepítőt oda, ahova mi szeretnénk. A letöltési cím egyébként a hibaüzenet melletti View log here gombra kattintva megjelenő naplófájlból is kicsalható, az én esetemben ez volt:

http://download.microsoft.com/download/D/A/5/DA588562-C4A4-4337-AE36-3A4548700CDF/inetmgr_amd64_v1.1_en-US.msi

Mielőtt elindítjuk a telepítőt, nyissuk meg az MSI fájlhoz tartozó Properties ablakot és a Compatiblity fülön álljunk vissza korábbi Windows verzióra:

inetmgr-compatibility

Nyomkodjuk végig a varázslót, indítsuk újra az IIS Managert és már kapcsolódhatunk is a szerverünkhöz, ahonnan előfordulhat, hogy az első alkalommal újabb modulok töltődnek le:

inetmgr-features

 

Technorati-címkék: ,

WSUS telepítése Windows Server 2012-re

A Windows Server Update Services telepítése Windows Server 2012-n alapvetően nem nehéz feladat: mivel az operációs rendszer része, még letölteni sem kell, csak végig kell nyomkodni a varázslót a Server Managerben. Aki nem hiszi el, nézze végig ezt a képes step-by-step útmutatót.

Ennek ellenére nekem nagyon nehezen jött össze. Ha telepítőkről van szó, én kétségkívül vonzom a hibákat, azonban a neten talált hihetetlen mennyiségű fórum bejegyzés arra utal, hogy nem vagyok egyedül. Íme a tapasztalatok.

Megjegyzés:
Az alábbi módszerek nálam működtek, de egyes esetekben magam sem tudom, hogy miért ez a megoldás a problémára. Csak saját felelősségedre próbáld ki!

A környezetről annyit, hogy egy frissen telepített WS 2012 tartományvezérlőről van szó, amin szépen megférne a WSUS. Nem találtam olyan leírást, ami arra utalna, hogy ez nem támogatott környezet.

NTFS jogok

A Prepare for Your WSUS Deployment című TechNet cikk szerint az NT Authority\Network Service felhasználónak Full Control jogokat kell adni az alábbi mappákra, különben a WSUS Administration snap-in nem fog jól működni:

  • %windir%\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
  • %windir%\Temp

Ebben az a szép, hogy – ahogy a dokumentáció is írja – az első útvonal nem biztos, hogy létezik, ha még nincs a gépen IIS. A WSUS-nak kell az IIS, és szerencsére elég okos a telepítő ahhoz, hogy szükség esetén a Web Role szerepkört is telepítse. Ráadásul még azt is tudja, hogy az IIS-nek mely komponensei kellenek a WSUS-hoz, tehát a “minimal install” elv jegyében érdemes a WSUS telepítővel telepíteni az IIS-t is. De akkor hogy adjunk jogot még a telepítés előtt a nem létező mappára?

Role Services

A telepítő varázslóban egyszer csak elérkezünk a Role services lépéshez:

WSUS install wizard: Select role services

Ha esetleg lelkesen bepipálnánk az összes komponenst, akkor készüljünk fel az alábbi hibaüzenetre:

The following features cannot be installed on the same server: Database, WID Database.

The following features cannot be installed on the same server: Database, WID Database.

Egy kis magyarázat, mert az elnevezések nem nyilvánvalóak:

  • A WID Database (ami alapértelmezés szerint be van pipálva) azt jelenti, hogy a telepítő feltelepíti a Windows Internal Database-t, ami egy mini SQL Server. Sok megkötése van, de a célra tökéletesen megfelel, különösen egygépes környezetben.
  • A Database (ami alapértelmezés szerint nincs bepipálva) azt jelenti, hogy a telepítő egy létező SQL Serveren hozza létre a WSUS adatbázisát. Ez lehet akár másik gépen is. Ha így döntünk, akkor mindenképpen olvassuk el a WSUS database requirements részt a dokumentációban, mert rengeteg megkötés van.

A lényeg: az alapbeállítás jó, nem kell mindent bepipálni.

Újraindítás eredmény nélkül

Előfordulhat, hogy a telepítő fut egy darabig, majd azt mondja, hogy:

The request to add or remove features on the specified server failed.

The operation cannot be completed, because the server that you specified requires a restart.

The operation cannot be completed, because the server that you specified requires restart.

Persze az ember újraindítja, de utána sem lesz jobb a helyzet, lehet elölről kezdeni a WSUS telepítést, aminek ugyanez lesz az eredménye.

A megoldás – és erre különösen nehéz ráhibázni – egy kis csoportházirend módosítás. Meg kell nyitni a Group Policy Management konzolt, és módosítani kell a Default Domain Controllers Policy-t. A Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment ágban található Log on as a service beállításnál fel kell venni az alábbi fiókokat: IIS_WPG, NETWORK, NETWORK SERVICE, SERVICE.

A házirend módosítása után természetesen a szokásos frissítés is szükséges admin parancssorból:

gpupdate /target:computer

Telepítés utáni feladatok

Miután a telepítő varázsló végigfut, találunk egy nem túl feltűnő Launch Post-Installation tasks linket, amire rá kell kattintanunk. Ez gyakorlatilag folytatja a telepítést.

Amíg el nem akad:

Configuration failed. A log file was created at C:\Users\felhasználónév\AppData\Local\Temp\tmpXXXX.tmp

wsus-post-installation

Bátran nézzünk bele a log fájlba, mert elég beszédes, és egyértelműen kiderül a probléma. Például:

Config file did not contain a value "ContentDirectory"
Microsoft.UpdateServices.Administration.CommandException: 
A required configuration value was not found in the system.

Ez azért különösen szép, mert egy olyan értéket hiányol, amit a grafikus telepítő megkérdezett, és amit természetesen meg is adtunk neki. A parancssor kedvelőinek jegyzem meg, hogy a C:\Program Files\Update Services\Tools mappában található egy wsusutil.exe segédprogram, amivel parancssorból el lehet intézni sok mindent, de itt nem segít.

Megsúgom, hogy a telepítő a C:\Windows\System32\ServerManager\ComponentConfiguration\UpdateServices-Services.xml fájlból hiányolja az értéket. Megnyitva a fájlt, ezt találjuk benne (áttördeltem az olvashatóság érdekében):

<?xml version="1.0" encoding="utf-16"?>
<INSTANCE CLASSNAME="ServerComponent_UpdateServices_Services">
<PROPERTY NAME="ContentDirectory" TYPE="string">
</PROPERTY>
<PROPERTY NAME="ContentLocal" TYPE="boolean">
<VALUE>true</VALUE>
</PROPERTY>
</INSTANCE>

Akinek van szeme az XML-hez rögtön észreveszi, hogy a ContentDirectory érték valóban üres. Semmi gond, egészítsük ki:

<?xml version="1.0" encoding="utf-16"?>
<INSTANCE CLASSNAME="ServerComponent_UpdateServices_Services">
<PROPERTY NAME="ContentDirectory" TYPE="string">

<VALUE>C:\WSUS</VALUE>
</PROPERTY>
<PROPERTY NAME="ContentLocal" TYPE="boolean">
<VALUE>true</VALUE>
</PROPERTY>
</INSTANCE>

Rendszergazdai jogosultságokkal indítva a Notepadet el is fogjuk tudni menteni a módosításokat. Így már tovább fut a telepítő.

Adatbázis

Nálam is tovább futott a telepítő, de nem végig. Ugyanígy készült egy naplófájl a Temp mappában, ezúttal ezzel a hibaüzenettel:

Fatal Error: SqlException (0x80131904): Invalid object name ‘SUSDB.dbo.tbSchemaVersion’.

Ez arra utal, hogy nem jó az adatbázis. A logból kiderül az is, hogy az adatbázis létezik, lehet hozzá kapcsolódni, csak épp a keresett tábla nem létezik.

Körülnéztem a C:\Windows\WID\Data mappában, ahol valóban megtaláltam a SUSDB.mdf és SUSDB_log.ldf fájlokat, tehát az adatbázis valóban megvolt, biztos egy korábbi telepítő már létrehozta. Az viszont gyanús volt, hogy ugyanúgy 2112 KB volt a mérete, mint a model.mdf fájlnak, amiből arra tippeltem, hogy ez az adatbázis bizony még szűz.

Ötlet: töröljük le az adatbázist, hátha a telepítő újra létrehozza, ezúttal jól. Érdekes módon a fájlt simán lehetett törölni, de a szolgáltatás újraindítása után a Log mappában lévő error.log fájlban egyértelműen látszott, hogy hiányolja.

Ez a módszer tehát nem jött be, korrekt módon kellene törölni az adatbázist, amihez viszont be kellene jelentkeznünk az adatbázis szerverre. Ha nem akarunk SQL Server Management Studiot telepíteni a szerverre, megcsinálhatjuk parancssorból SQLCMD-vel, ami önállóan is letölthető innen: Microsoft Command Line Utilities 11 for SQL Server

A System Requirements szekcióban megtaláljuk – vagy ha nem, akkor majd az MSI elindítása után közli velünk, – hogy ennek bizony kell az ODBC Driver 11 for SQL Server is.

A két telepítő MSI fájl letöltése önmagában sem egyszerű a szerveren lévő Internet Explorerből. Egyrészt mert a böngésző agresszívan blokkolja a felugró ablakokat, másrészt mert:

Security Alert: Your current security settings do not allow this file to be downloaded.

wsus-ie-msi-download-error

Ha a böngészővel nem akarunk harcolni, az összesen 7MB-nyi tartalmat letölthetjük másik gépen is, és átvihetjük például Remote Desktopon keresztül.

Ha már van SQLCMD, akkor jó lenne azt is tudni, hogy hol. Itt:

C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn

A kapcsolódáshoz kelleni fog egy connection string, ami WID esetén így néz ki:

np:\\.\pipe\MICROSOFT##WID\tsql\query

Én az SQLCMD-t mindig úgy használom, hogy a parancsokat fájlba írom, mert úgy a legkönnyebb újra futtatni őket. Például egy wsus.sql fájlba:

select name from sys.sysdatabases
drop database susdb
select name from sys.sysdatabases

Futtassuk le:

sqlcmd -S np:\\.\pipe\MICROSOFT##WID\tsql\query -i c:\temp\wsus.sql

Adatbázis eldobva, így már a telepítő sikeresen létrehozza, sőt a megfelelő táblákat is megalkotja benne. Elindul a WSUS Administration konzol, a konfigurációs varázsló és megy is minden szépen.

Nem maradt más hátra, mint a kliensek beállítása és az SSL konfigurálása.

 

Technorati-címkék: ,,