Windows Sysinternals has a range of pretty neat tools. My favorite is PsExec – which lets me execute programs on a remote computer. It’s like Remote Desktop – but with the console. Or you could think of it as a Windows alternative of SSH – if you’re a *NIX guy.

It’s perfect when you need to restart a server where Remote Desktop Services is fubar.

I can execute

psexec \\myWebServer cmd.exe

and I am now running a console window on the webserver.

It is also handy when scripting/automating tasks – such as building, deploying and making backups of software projects.

But invoking PsExec from TeamCity isn’t a walk in the park, to say the least. PsExec does some funky things with the standard input/output, and invoking this from Java (which TeamCity is built on) raises all kinds of problems and stability issues.

Luckily – Powershell takes care of business.

The script below stops an IIS 7 ApplicationPool on a remote server.

[string]$HostName = “myWebServer”
[string]$Cmd = “C:\Windows\System32\inetsrv\appcmd.exe stop apppool MyMainAppPool”
Invoke-WmiMethod -class Win32_process -name Create -ArgumentList ($Cmd) -ComputerName $HostName

Change $HostName and $Cmd in order to run other commands.

As Webstep guru Thor Halvor explained in the this excellent blogpost – there are security restrictions to prevent/limit cross domain access of XMLHttpRequest’s – the cornerstone of AJAX.

Flash and silverlight has the same restrictions – and solves this by using crossdomain.xml and clientaccesspolicy.xml. These files are placed on the server you want to communicate with – and must contain * or the domain you want to contact the server from.

Anyways – there is a similar mechanism that XMLHttpRequest supports. This mechanism is called CORS – Cross-origin resource sharing. It is a newer(2004) and preferred alternative to JSONP – and works more or less like the xml files mentioned above. The only difference is that it isn’t implemented as a file – it’s part of the HTTP Header. This makes it a bit more difficult to set up than the others.

When a javascript on siteA wants to make a request to siteB – then the script first makes an initial OPTIONS request to site B – and looks at the HTTP Header it receives.

Access-Control-Allow-Origin: *

If the value is * – then it means that XmlHttpRequests can communicate with that site – from any other server – and a regular XMLHttpRequest can be made just like you were communication with your own server. You can of course type in domain names here to prevent everybody from using your API.

Here’s how to configure this on an Microsoft IIS Server – Web.Config – under the <configuration> node

<system.webServer>
  <httpProtocol>
    <customHeaders>
       <add name="Access-Control-Allow-Origin" value="*" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

So to sum it up: use CORS whenever possible, instead of hacking your way around with JSONP. You’ll have prettier code, better error handling and it’s safer to use with regard to XSS Attacks as far as I have understood. Also – CORS supports all types of HTTP requests (Get/Post/Put,Delete), while JSONP only supports Get.

Read more about CORS here:
http://my.opera.com/core/blog/2011/10/28/cors-goes-mainline

A third (and the newest) alternative is UMP – I might blog more about this some other time.

En del av IIS sin innebygde sikkerhet nekter brukere å laste ned filer som normalt kjører på serveren. F.eks. så blir *.aspx prosessert på serveren, og output kommer som en html side. Noenganger kan det imidlertid være ønskelig å la brukere laste ned noen av disse filene som brukes av asp.net rammeverket – f.eks. .resx filer (som er xml språkfiler).

Dersom du legger resx filen på website’n din og prøver å åpne den i en nettleser får du en HTTP 404 feil – selv om filen faktisk ligger der.

For å få dette til å fungere i IIS 7.0 så gjør følgende:

1. Gå inn i IIS Manager, og lag en ny Application Pool. Velg No Managed Code – som .Net Framework version. Vi vil ikke at .net rammeverket skal gjøre noe her, vi er ute etter statisk filserving.
   




2. Lag en egen undermappe i websiden din der du vil plassere resx (etc) filene. Høyreklikk på mappen og velg Convert to Application. Under valget om Application Pool, så velg  resxPool (den du lagde i forrige steg).




3. Velg resx mappen i IIS Manager, og dobbeltklikk på Mime Types i hovedvinduet.  Legg til resx mime type. Dette gjør at IIS skal serve slike filer når en browser ber om det.
   




4. I teorien skal det nå fungere, men vi må i gjennom en siste sikkerhetsbarriere. IIS har nemlig noen globale instillinger som sier at den aldri skal serve .resx filer. Denne innstillingen finnes i
   C:\Windows\system32\inetsvr\config\ApplicationHost.config.

   Lokaliser
   


   og sett denne til true. (Denne filen må kopieres ut (til f.eks. skrivebordet), editeres her, og kopieres tilbake pga filtilgang)
   

Du skal nå klare å laste ned resx filer som ligger i mappen du lagde på web serveren.

For å laste opp store filer (eller f.eks. sende store bytearray’er via Web Services) inn til en Microsoft IIS server kreves det en liten tweak.

I IIS 6.0 holdt det å justere opp maxRequestLength parametren i web.config. I IIS 7.0 må man også legge til/endre under <system.webServer>. Eksempelet under tillater å laste opp filer som er 2 GB store (IIS 7.0 støtter ikke større mengder såvidt jeg vet).