Publish from VS2010 Beta 2 to Windows Server 2008 R2 (IIS 7.5)

28 01 2010

Heute ist es mir nach stundenlangem rumprobieren endlich gelungen, die “Publish” Funktion in VS2010 Beta 2 für den Upload einer Web-Applikation auf einen WIndows Server 2008 R2 zum Laufen zu bringen. Folgende Hinweise waren dabei entscheidend:

  1. Die Installation des Web Management Services alleine ist nicht ausreichend. Stattdessen müssen sämtliche Komponenten von Web Deployment Tool 1.0 installiert werden. Welche der damit zusätzlich installierten Komponenten jetzt wirklich nötig waren, ist unklar.
  2. Es ist nicht ausreichend, im Internet Information Services (IIS) Manager für die Web Site unter IIS Manager Permissions einen Windows User hinzuzufügen, der sämtliche Schreibrechte auf das physikalische Verzeichnis (z. B. C:\Inetpub\wwwroot) hat.
  3. Vielmehr müssen stattdessen in VS2010 die Credentials (Username/Passwort) eines Benutzers angegeben werden, der auf dem Zielrechner Administratorrechte hat. Dieser Benutzer braucht nicht bei den IIS Manager Permissions eingetragen zu werden, da Benutzer der Administators Gruppe automatisch auch die nötigen IIS Manager Permissions besitzen. (Offensichtlich wird während der Installation mehr gemacht, als nur Dateien zu kopieren. Was genau das ist, konnte ich bisher nicht herausfinden.)

Die folgenden grundlegenden Hinweise sind eher trivialer Natur, müssen aber natürlich trotzdem beachtet werden:

  1. Der Web Management Service muss laufen. Per Default wird er als Service mit dem Start-Type “Manual” installiert.
  2. Der TCP Port 8172 muss in der Windows Firewall geöffnet werden. Eine entsprechende “Inbound-Rule” wird auf dem Windows Server bei der Installation des Web Management Service automatisch angelegt und enabled. Bei Windows 7 hingegen wird die Rule zwar angelegt, sie ist jedoch nicht enabled.
  3. Im “Publish Web” Dialog von VS2010 darf unter “Service URL” weder die Portnummer (:8172) noch /MsDeploy.axd angegeben werden. Diese werden durch VS2010 zusätzlich angehängt. Ist wohl noch ein Bug in der Beta 2.
  4. Falls die Web-Applikation in einem Subfolder einer Website installiert werden soll, ist das unter “Site/Application” z. B. so einzutragen: “Default Web Site/<AppName>”, also Website, Schrägstrich, ApplicationName.
Advertisements




ASP.NET 4 Beta 2 on Windows Server 2008 R2

28 01 2010

Heute habe ich über 3 h damit verbracht, eine ASP.NET 4 Beta 2 (ASP.NET MVC 2 Beta 2) Web-Applikation auf einem Windows Server 2008 R2 zum Laufen zu bringen.

Es gab die merkwürdigsten Fehlermeldungen v. a. HTTP Error 404.0, Resource not found in Verbindung mit dem “StaticFileHandler” beim Zugriff auf eine ASP.NET MVC Controller Action. Selbst eine einfache ASP.NET Seite (default.aspx) führte nur zu einer Fehlermeldung.

Die Lösung habe ich letztendlich hier gefunden. Und so sieht sie aus:

%windir%\Microsoft.NET\Framework\v4.0.21006\aspnet_regiis.exe -i





SQL Server 2008 Express Remote Zugriff

27 01 2010

Es gibt mal wieder Probleme beim Remote Zugriff auf einen SQL Server 2008 Express SP1 (Named Instance). Folgendes wurde auf dem Server (Windows Web Server 2008 R2) bereits eingerichtet bzw. überprüft:

  1. Service “SQL Server” läuft.
  2. Service “SQL Browser” läuft.
  3. SQL Server TCP/IP-Protokoll ist enabled, die Portnummer für IPAll steht auf 1433 (also keine "dynamic Ports”).
  4. Windows Firewall für TCP Port 1433 ist offen (nur für Service “SQL Server”).
  5. Windows Firewall für UDP Port 1434 ist offen (nur für Service “SQL Browser”).
  6. Der Zugriff von einem lokalen SQL Server 2008 Management Studio Express über tcp:<ipaddress>\SQLEXPRESS funktioniert (Windows Authentication).

Hilfreiche Hinweise insbesondere zur Verwendung des PortQry Tools habe ich in diesem Blog-Beitrag gefunden:

SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified

Und hier die Ausgabe des PortQry Tools:

C:\PortQryV2>portqry.exe -n ###.###.###.### -p UDP -e 1434

Querying target system called:

###.###.###.###

Attempting to resolve IP address to a name...

IP address resolved to

querying...

UDP port 1434 (ms-sql-m service): LISTENING or FILTERED

Sending SQL Server query to UDP port 1434...

UDP port 1434 (ms-sql-m service): FILTERED

Vermutlich liegt es an einem geblocketen UDP-Port 1434 (SQL Browser) durch eine hardwareseitige Firewall vor dem Server. Wir werden sehen…

Update: Nach Rücksprache mit dem Provider liegt vor dem Server keine Firewall und bei ihm geht es auch. Es kann also nur noch an einer clientseitigen Firewall liegen. Ein Deaktivieren der clientseitigen Windows Firewall hat allerdings keine Veränderung gebracht. Bleibt eigentlich nur noch die Firewall oder irgendwelche NAT-Probleme im DSL-Router.

Eine Lösung ist allerdings das direkte, explizite angeben des TCP-Protokolls und der TCP-Portnummer im SQL Server Management Studio Connect Dialog:

tcp:<ipaddress>\<instancename>,1433

image

Die Lösung hat den Charme, dass man serverseitig weder den SQL Browser Service benötigt noch die Firewall für den UDP Port 1434 öffnen muss.





VMware 64-bit Guest OS on 32-bit Host OS

8 01 2010

Es ist möglich, ein 64-bit Gast-Betriebssystem (z. B. Windows Server 2008 R2) auf einem 32-bit Host-Betriebssystem (z. B. Windows 7 Ultimate x86) zu installieren. Heute ist mir das auf meinem DELL XPS M1530 Notebook mit dem VMware Player 3.0.0 build-203739 gelungen.

Voraussetzungen dafür sind:

  • Der Prozessor muss 64-bit fähig sein (hier: Intel Core2 Duo 2,40 GHz T7700).
  • Prozessor und BIOS müssen VT (“Virtualization Technology”) Unterstützung bieten. Ggf. ist das im BIOS zunächst zu aktivieren.

Der 2. Punkt ist auf dem DELL XPS M1530 problematisch, weil die VT-Unterstützung im aktuellen BIOS (A12) deaktiviert und auch nicht über das BIOS Setup aktivierbar ist (Option fehlt!). Erst durch einen Downgrade auf BIOS A08 wurde die Option wieder sichtbar und ließ sich aktivieren.





AllUsersAppData in JScript

5 01 2010

Die Ermittlung des Pfads des “AllUsersAppData” Ordners (vgl. SHGetFolderPath(CSIDL_COMMON_APPDATA) in C++, z. B. C:\Documents and Settings\All Users\Application Data in einem englischen Windows XP) ist in JScript nicht so einfach, da hierfür kein Identifier in der SpecialFolders Collection definiert ist. Stattdessen geht es so:

var objShell = new ActiveXObject("Shell.Application");
var objFolder = objShell.Namespace(0x23);
var objFolderItem = objFolder.Self;
WScript.Echo(objFolderItem.Path);

Anstelle von 0x23 können natürlich auch andere Konstanten für andere (virtuelle) Ordner verwendet werden. Das folgende Script zeigt alle bekannten Ordner an:

var msg = "";
var objShell = new ActiveXObject("Shell.Application");
for (i = 0; i <= 255; ++i)
{
  var objFolder = objShell.Namespace(i);
  if (objFolder != null)
  {
    var objFolderItem = objFolder.Self;
    msg += i + " " + objFolderItem.Path + "\r\n";
  }
}
WScript.Echo(msg);