Archive for the ‘IIS’ Tag

Enabling the IIS Management Service on Server Core 2012   Leave a comment

Install the IIS Management Service (assuming IIS is already installed)

  • Open an elevated Powershell session
  • Run: Install-WindowsFeature -Name Web-Mgmt-Service
  • Run: sc config WMSVC start=auto
  • Run Regedit.exe and navigate to HKLM\Software\Microsoft\WebManagement\Server
  • Change the binary value of EnableRemoteManagement from 0 to 1
  • Run: Start-Service WMSVC

Optional: Enrol a certificate from an internal AD CA

  • Open an elevated Powershell session
  • Launch Notepad
  • Add the following lines to the new file:
    [NewRequest]
    Subject=”cn=yourServer.yourDomain.com”
    Exportable=TRUE
    [RequestAttributes]
    CertificateTemplate=”WebServer”
  • Save the file as something ending in .inf, for example iis.inf
  • Run: certreq -new d:\temp\iis.inf d:\temp\request.txt
  • Run: certreq -submit d:\temp\request.txt d:\temp\iiscert.cer
  • Run: certreq -accept d:\temp\iiscert.cer

Optional: Changing the listener certificate

  • Open an elevated PowerShell session
  • Run: Get-ChildItem -Path “cert:\localmachine\my”
  • Copy the thumbprint for the certificate you enrolled above
  • Run the following
    netsh
    http
    del sslcer ipport=0.0.0.0:8172
    For the next command, replace yourCert with the thumbprint copied from step 3:
    add sslcert ipport=0.0.0.0:8172 certhash=yourCert appid={00000000-0000-0000-0000-000000000000} certstorename=MY verifyrevocationwithcachedclientcertonly=disable usagecheck=enable dsmapperusage=disable clientcertnegotiation=disable
  • Run: show sslcer, just to just to check the binding was successfully applied with the nominated settings (even if the output from the above command was successful)

Assuming you completed the optional steps, you can now bind to the IIS Management Service without receiving the certificate trust warning.

If you elected to skip the optional procedures, you will still be able to connect, you’ll just have to put up with the warnings.

Cheers,
Lain

IIS7 and UNC-based virtual directories.   2 comments

Today threw up another one of those wonder “if you say so” type errors. This time, it was with IIS7 on Windows Server 2008 SP2 (not R2, in this case). If you want to skip the story, head to the end for some tips on troubleshooting the issue (keep in mind though that this is for a specific issue, mainly revolving around apparent access denied and server HTTP 500.19 errors).
 
We house our intranet photos on the server that also houses related data, and one of our team is in the process of drumming up a new web application that he wanted to use the photos in. This led to the fairly common scenario of wanting to create a virtual folder on his web server that pointed to the JPEGs on the external server.
 
Now, in the days of IIS6, this was both simple and intuitive, but woe unto me for trying to get this going in a hurry on IIS7! Strictly speaking, the resolution is very few steps, but as per usual, I was trying to jump into something feet first without having kept myself up to date with yet another component’s changes. As a refresher, under IIS6, all one had to do was create the new virtual directory and utilise the “connect as” and voila, you were done. The “tricksy” (just watched Lord of the Rings yesterday, and I had to find a reason to use that word!) nature of this task in IIS7 is the UI looks pretty much the same. However, I ran into half a days worth of dramas while I tried to work through what the issue was.
 
As part of the diagnostic process, I quickly established via the Security event log that for whatever reason, IIS7 was trying to verify this “connect as” account existed locally before using it to connect with the foreign system. This was borne out by the fact that there were no entries in that servers event log – not even anonymous ones. That problem was taken care of inside of the first five minutes of looking at this issue by simply creating a local account with the same username and credentials. Okay, but we still didn’t have liftoff, Captain. Why not?!
 
At this point, I was still getting a lot of errors, and they all seemed to get back to the good old “Access Denied” root cause, which of course I didn’t buy because I had verified with a net use command that access wasn’t in fact the issue. At least, it wasn’t an issue with the “connect as” account, and a quick scan of the foreign Security event log confirmed that the computer account – for whatever reason, was trying to authenticate with this foreign machine. That was never going to happen, since the foreign machine is a workgroup machine, unlike the IIS7 server which is domain joined. The error indicated was HTTP error 500.19.
 
Naturally, I decided that was an oversight on my part and headed straight to the Authentication applet to enable Windows authentication, except I couldn’t get into the applet. After double clicking it, the status column remained stuck on something to the effect of “refreshing”, much to my annoyance, and trying to open any option was bringing up a new error that the web.config file couldn’t be found. Suffice to say I was a little bewildered. A web.config for a virtual directory? I don’t think so, Tim.
 
So, jumping to the end of this chain of events, I ended up deleting the virtual directory, going back to the site root and enabling Windows Authentication at that level, then recreating the virtual directory, and lo and behold, it worked exactly as it should of from the outset!
 
 
So, in point form, here’s what I found to be different from IIS6:
  • Connect As account needs to exist locally on the IIS7 server if both the IIS7 server and the foreign host do not live in the same domain (or forest, if you want to expand into larger topologies).
  • You may need to enable one of the additional authentication mechanisms before you create the virtual directory to avoid the 500.19 errors the server will throw if it’s trying to track down the web.config file. Personally, I used the Windows Authentication option, but I suspect the others would have their uses depending on what you’re hosting your content on.
  • When filling out the Connect As window, do NOT use the local hostname in front of the account name, as that creates a disassociation between the local version of the Connect As account and the foreign system’s version. This is one point you should pay extra attention to, as I read a number of articles suggesting you should in fact use the hostname. As I said already, do NOT do this under IIS7. So, to use an example, you want to use “JohnDoe” as the username, and not “hostname\JohnDoe”.

Anyway, as I say, the change itself is just as quick to make as it ever was, there’s just a few things to watch out for in terms of new configuration traps.

Cheers,
Lain

Posted February 9, 2010 by Lain Robertson in Windows Server 2008

Tagged with , , , ,