single server - Windows Server 2012 R2 and Exchange 2013 Standard

Exchange mail flow is working but couldn't access OWA
checked IIS and the Default Website is stopped, tried to restart but no luck
clicked to View Virtual Directories and don't see any?
Exchange Back End is running and the virtual directories are there
Was going to recreate the Default Website virtual directories using power shell but it fails to connect
winrm qucikconfig shows it's already setup and running

How to correctly recreate the virtual directories for the Default Website without access to ps?

Thanks

update:
Since I can't connect to Exchange Shell Management, I added the snapin to Windows powershell.
I then ran the following commands, substituting my server name for ServerName:
Remove-OwaVirtualDirectory ServerName\owa (Default Web Site)
Remove-OwaVirtualDirectory ServerName\owa (exchange back end)

This seemed to work, asking me for confirmation, so I then attempted to run the following commands, substituting my server/domain:
New-OwaVirtualDirectory  -InternalUrl https://ServerName/owa -ExternalUrl https://mail. domain.com/owa
New-OwaVirtualDirectory  -InternalUrl https://ServerName/owa -ExternalUrl https://mail.domain.com/owa -WebSiteName Exchange Back End

But this failed for each, returning a message that the website doesn't exist?
Of course they don't, so this makes no sense?

• Edited by trythis Monday, June 08, 2015 1:35 AM

I think you need to find out why the default web site won't start before doing anything about virtual directories, since they all depend upon it being up and running. Do you see any error messages or events that say why it isn't starting? If it's anything like E2010 (and most E2013 things are), it will be looking for the site with the specific ID number 1 (which is what IIS gives the out-of-the-box default web site). Recreating the default web site generally ends up with a random ID, regardless of the name you give it, and this confuses things a bit.

Message is "This website cannot be started. Another website may be using the same port."

But I've checked the bindings and don't see any duplicate entries for port 443, which is the culprit.

If I remove 443, the website will start. As soon as I add 443 on All Unassigned, the site immediately stops

I'm thinking there is a duplicate in one of the config files? Could it be a miss-configured/corrupted certificate?

It's set to use the Microsoft Exchange self-signed cert.

Which port number is the Back-End site listening to for SSL? If you stop it, can you then start the default web site?

if you go to https://servername , does anything respond?

444

No, stopping the Exchange Back End site has no affect on being able to start the Default site.

also, I can't access the Exchange management shell so I added the Exchange snapin to powershell and ran:
Get-AutodiscoverVirtualDirectory

which gave me this (i've edited the server.domain):

WARNING: IIS://myserver.mydomain.local/W3SVC/1/ROOT/Autodiscover wasn't found. Please make sure you've typed it correctly.

• Edited by trythis 14 hours 43 minutes ago

If I wanted to restore just the Default Website from a backup, which I have, do you know which files/folders to include?

It's not something I've had to do, so I don't really know the answer to that.

I do know that IIS makes regular backups of the config files in

C:\Windows\System32\inetsrv\config

into subfolders in the

C:\Inetpub\history

hierarchy.  It might be worth comparing a few of these in notepad.  In fact, having a look at the current applicationHost.config might show an unexpected listener for 443.

Thanks going to check out the history files. Already checked the applicationHost.config but nothing unusual there.

Is there a forum just for backing up and restoring Exchange/IIS?

Probably not specifically for backing up, but there is always

http://forums.iis.net/

http://forums.iis.net/t/1180372.aspx?Why+is+IIS+forum+separate+from+Technet

Good news, I got the Default Website back. And the Get-AutoDiscoverVirtualDirectory runs without error.

Now, any suggestions on why it still won't start?

I have a feeling it has something to do with certificates since it's only port 443 that's problematic.
Now wondering if there's a backup of the certificate stores?

I don't think serious certificate problems generally prevent the site from actually starting up. You normally just get a 500 error or something when someone tries to access them.

Does anything respond if you go to https://servername ?  It's not unknown for some applications to install their own web services.  Maybe you had to install apache as a pre-requisite of something else?

One thing you might try is to see if anything else is using port 443 with

netstat -an | find "443"

see anything wrong here?

also for https://domain.com

I get this:

SSL connection error

ERR_SSL_PROTOCOL_ERROR <button class="text-button small-link singular" id="details-button" jscontent="details" jsdisplay="details" jstcache="4" jsvalues=".detailsText:details; .hideDetailsText:hideDetails;" style="-webkit-user-select:none;border:0px;border-radius:2px;color:#696969;cursor:pointer;float:none;font-size:0.875em;margin:0px;padding:10px 0px;-webkit-transition:box-shadow 200ms cubic-bezier(0.4, 0, 0.2, 1);transition:box-shadow 200ms cubic-bezier(0.4, 0, 0.2, 1);text-decoration:underline;box-shadow:none;min-width:0px;background-image:inherit;background-attachment:inherit;background-size:inherit;background-origin:inherit;background-clip:inherit;background-background-repeat:inherit;">Hide details</button> Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.

Well, it does look as if it is listening on port 443, and something is connected to it, too.

You can find out which process is listening by adding b to the list of switches for netstat, but you may need to run the cmd prompt as administrator.  It also takes longer, so piping it to find.exe might keep you waiting a while.  So first try

netstat -anb

and look for 443 in the results, and see what the executable is.  If that came back quickly, try looking for 443 again with

netstat -anb | find "443"

pid 4, seems like cert stuff?

I also noticed this in the system events:

The World Wide Web Publishing Service (WWW Service) did not register the URL prefix https://127.0.0.1:443/ecp for site 1. The necessary network binding may already be in use. The site has been disabled. The data field contains the error number.

??

I can't tell from the PID.  It would be good to see the executable name.  Unfortunately, if I do

netstat -anb > C:\test.txt

then open it in notepad to see what's using it, I only get

TCP    0.0.0.0:443    0.0.0.0:0    LISTENING
 Can not obtain ownership information

so it can't find IIS for some reason.  I suppose another way would be to stop the WWW service, and do the netstat again.  If no 443 entries are shown, then we can be sure that it really is IIS listening, and not something that's hijacked it.

444

No, stopping the Exchange Back End site has no affect on being able to start the Default site.

also, I can't access the Exchange management shell so I added the Exchange snapin to powershell and ran:
Get-AutodiscoverVirtualDirectory

which gave me this (i've edited the server.domain):

WARNING: IIS://myserver.mydomain.local/W3SVC/1/ROOT/Autodiscover wasn't found. Please make sure you've typed it correctly.

• Edited by trythis Monday, June 08, 2015 4:43 PM

I can't think of anything else to look at now. Maybe IIS really is listening, or maybe there is just a misconfiguration somewhere that makes everything think it is. I think it'd be best to ask in the IIS forum, since this is more of an IIS problem than an Exchange one.

4 still listening after stopping www?

Is it?  It does seem strange.  I'm not sure how you find what process ID 4 is.  It'll probably be in task manager (if you select 'Show Processes for all Users'), but it'll probably just say 'System' - it's so low.

If you're absolutely sure that it is listening on 443 even when IIS is stopped, then maybe some other service has been misconfigured to use 443.  It could be anything, like IMAP, or anything at all.  I don't know how you find out, other than to stop everything until netstat shows it not listening.

Bit the bullet and brought in MS Support (it took them several hours to correct the situation).

Long story short, do NOT put Exchange on a box that has DirectAccess installed or vice versa!

Any IISReset will expose port 443 to DA and it will grab that port.

Once that happens, the Default Website will not start.

Good luck finding this from netstat.

In my case DA was already on the server, Exchange was installed and everything worked ... until...

Something, still not sure what, prompted the IISReset as I never knowingly performed that reset until after the problem appeared. The only solution, and it's a temporary fix, is to delete a single registry entry and reboot the server. The Default website will then start and you'll be good to go ... until ... the next IISReset, in which case you'll need to repeat the delete/reboot process.

https://support.microsoft.com/en-us/kb/2980660