Later on in the year I’ve got a big RSA and SharePoint deployment, as I know ‘Zippity Squat’ about SharePoint, I thought the best way to get some hands on experience, was to work out how to integrate SecureID with Exchange 2013, (which I know a few things about!)
Solution
I’m assuming you already have RSA Authentication Manager setup and users/tokens deployed. This run though is simply to get your RSA solution working with Exchange/OWA
1. Create a user in Active Directory, (here I’m using SVC_RSA_Access), and ensure that user has a mailbox, you can do this in the Exchange Admin Center, but I prefer to use the shell.
6. We need to have the .Net 3.5 Feature added. (Server Manager > Add Roles and Features).
7. Log onto the Security Console of your RSA Authentication Manager appliance > Access > Authentication Agents > Generate Configuration File > Follow the wizard > Download the file.
8. Place the file you downloaded (sdconf.inf) on the Exchange server in the C:Windowssystem32 folder.
9. Download and install the RSA Authentication Agent for Web for IIS, Install and accept all the defaults, it should locate the config file you have just downloaded.
10. On the Exchange server launch ‘RSA Web Agent’, and don’t be surprised when IIS Manager opens.
One of the often overlooked tasks of a PKI deployment is setting your Certificate Services CRL. For smaller deployments, with only one server then you don’t have to worry about how this will be designed (though a CRL does not have to be hosted on a Certificate Services server). In my test environment I only have one PKI server so everything will be going on that one box, In more complex environments you may have multiple root and subordinate PKI servers writing to your CRL (you may even have multiple CRL’s).
Solution
I would consider this a ‘post’ certificate services install task, so I’m assuming you already have that installed and configured.
1. Launch the Certification Authority management console > Right click the server-name > Properties > Extensions tab.
2. With CRL selected > Add > Type into the location http://crl.{your-domain-name}.{your-domain-extension}/crld
Note: You can use https:// but you may need to add a certificate in IIS manager and select ‘require TLS’ for the crld virtual directory.
3. In the variable section, select then ‘Insert’ the following onto the end of the URL;
Note: Is ‘should’ look like http://{FQDN-Of-Server}/crld/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
4. With the CRL entry you have just created selected > Enable the following two options;
Include in CRL’s. Clients use this to find Delta CRL locations.
Include in the CDP extension of issues certificates.
Apply > OK > Yes.
5. Change the ‘Select extension’ drop down to ‘CRL Distribution Point (CDP)’ > Add > Type in a UNC path as follows ‘{Server-name}crldist$ > Then select and inset the variables onto the end of the path, (like you did above);
<CaName>
<CRLNameSuffix>
<DeltaCRLAllowed>
And then (as above) add .crl onto the end of the path > OK.
6. With the CDP selected > Select the following options;
Publish CRL’s to this location
Publish Delta CRL’s to this location
Apply > OK > Yes.
Windows DNS Requirements for CRL
7. So that your clients can resolve the name of the CRL you have just created, they need to be able to resolve the name you just created. On your DNS server open the DNS management console > Expand server-name > Forward Lookup Zones > {your-domain-name} > Right click > New Host (A or AAAA) > name crl > IP address = The IP address of the IIS server that will host the CRL > Add Host > Close DNS Manager.
Windows IIS Requirements for CRL
8. On the web server, open the Internet Information Services (IIS) Manager console > Expand and select your server-name > right click > Add Virtual Directory >Set the alias to CRLD.
9. Under ‘Physical path’ select the browse button > Select the C: Drive, (or another drive if you wish) > Make New Folder > Call the folder CRLDist > OK > OK.
10. Select server-name > Directory Browsing
Note: If you are serving other services from this web server, you might wish to only set directory browsing on the CRLD virtual directory.
11. Enable.
12. Select the CRLD directory (Click refresh if you cant see it) > Configuration Editor.
13. Navigate to System.webServer > security > RequestFiltering.
Note: On older versions of IIS, it’s under ‘System.webServer > security > authentication > RequestFiltering.’
14. Change allowDoubleEscaping to ‘True’ > Apply.
Windows Folder Permission Requirements for CRL
15. Navigate to the folder you just created (i.e C:CRLDist) > Right Click > Properties > Sharing > Advanced Sharing > Select ‘Share this folder’ > Add a dollar symbol to the end of its name i.e. CRLDist$.
Note: This simply creates a ‘hidden’ share, that cannot be seen when browsing the server shares.
Note: In Addition, Set the Windows NTFS Permissions for the Server(s) to Full Control also.
16. Permissions > Object Types > Add in Computers > OK > Enter the name of the server(s) that need to write to the CRL > OK.
17. Grant the Full Control permission to the sever(s) you just added > Apply > OK.
18. Back at the Certificate Services server > Launch the Certification Authority management console > Revoked Certificates > Right click > All Tasks > Publish > New CRL > OK.
19. If you check the folder you created earlier, you will see it now contains the CRL files.
Related Articles, References, Credits, or External Links
I spun up a new Certificate Services server on my test network today, because I needed to issue some certificates for something I’m working on. It was a pretty vanilla build, just the Certificate Services role, and the Web Enrollment feature.
Solution
I spent a while searching this one down, as you can see (above) it was showing me the root cause of the problem. The page you normally see when you log into the web portal is default.asp, and that file is not in that folder.
1. Open IIS manager and then open the settings for the CertSrv virtual directory. Use the browse button to change the location.
2. Change the location to the sub folder en-US (or if you are in a different locale select your local one). > OK > OK.
3. Restart the web services and try again.</p?
Related Articles, References, Credits, or External Links
Since Exchange 2007, its management tasks have been done via PowerShell, (yes even the GUI Management). Which is fine, however it runs all that PowerShell from a virtual directory that lives in the servers’ IIS webserver. When that fails or there is a problem, Exchange runs quite happily, but you can’t run the management tools.
There are a number of reasons for this to fail and a number of different error messages, I will list them as I come acoss them.
Error 1 (Seen 16/10/12)
Error: Connecting to the remote server failed with the following error message: The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: “winrm quickconfig”. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command ‘Discover-exchangeserver- useWIA $true – suppressError $true’ -CurrentVersion ‘Version 14.1(Build 218.15).
I got the same when trying to access the Exchange Management Shell as well.
Update 16/10/12: I got this problem today again! It seems AVG 2012 causes this problem as well, if you have AVG installed remove it and try again.
Solution (Error 1)
1. Firstly drop to command line > then (as asked) run “WinRM QuickConfig”. Carry out any changes that it asks by simply pressing “y”.
2. Run the same command again untill it returns two positive results.
3. Start > Run > Services.msc {enter} Locate the following three services, make sure that they are set to “automatic startup” and are running.
IIS Admin Service Windows Remote Management (WS-Management) World Wide Web Publishing Service
4. Start > Administrative Tools > Expand Sites > Default Web Site > Make sure the default web site IS STARTED.
THIS WAS MY PROBLEM! If you can see the green start arrow then its NOT started.
5. When I attempted to start the default web site I got the following error:
Error: The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020).
Essentially one or both of the two comms ports that IIS uses (Port 80 HTTP and Port 443 HTTPS) have been taken by another process or program. Have a common sense check, what’s been installed on this server that might have a “web portal”? UPS software, AV software, another web server like Apache for example?
To find out what process is using the port
6. Close down any open windows that you have on the server. At command line issue the following two commands:
The fist checks for programs using port 80, In my case there were none, the second command checks port 443, heres my culpritt. All I know at this point is it’s PID (in the example below 4852).
7. To find out what that PID is, right click your Task bar > Launch Task Manager > Processes Tab > View > Select Columns.
9. Sort the PID column (by clicking on the column title) locate the PID in question, find out what it is. Once you know that stopping it will not harm the server, then simply right click and “End Process Tree”.
Note: Some legitimate important Windows processes might be using these ports like “lsass” and “system”.
10. Now you should be able to start the default website, and the Exchange Management Console should open correctly.
WARNING: You have not fixed the problem! (Just identified it), the software that hijacked the IIS ports needs uninstalling, or changing so that it uses a different port.
Error 2 (Seen 02/05/13)
Connecting to the remote server failed with the following error message: The WinRM client… cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command ‘Discover-exchangeserver- useWIA $true – suppressError $true’ -CurrentVersion ‘Version 14.1(Build 218.15).
And from the Exchange Managent Shell;
Other Symtoms;
Attempting to open OWA gives a 500 – Internal server error. (If that’s the only problem and it’s SBS 2011, make sure the ‘Microsft Exchange Form Based Authentication’ service is running).
Solution (Error 2)
I spent an entire afternoon fighting with this error on an SBS 2011 server! Every post I found on the internet did NOT fix it. Not even this one (which was so close) but my envirnment variables were correct
The EMTShooter did not help either, I checked it’s recommendations. and they were all correct.
The bottom line is: This is an IIS problem not an Exchange one, the site I was at had done a lot of work on this server and just installed some third party software, (that may or may not have changed some IIS configuration settings). So I connected to another working SBS 2011 Server and copied the contents of the c:inetpubwwwroot folder to the affected machine (back it’s contents up first!). Then run the following command;
[box] iisreset [/box]
If you don’t have access to a working SBS 2011 server, here you go, (you owe me a vodka!)
Error 3 (Seen 30/04/14)
“The attempt to connect to http://server.domain.com/PowerShell using “Kerberos” authentication failed: connecting to remote server failed with the following error message : The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and firewall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.”
One of the big drawbacks of Exchange management being built on PowerShell, and it talking to the PowerShell virtual director is, when IIS has a problem, you can’t manage your Exchange via the command shell, or the Exchange Management Console.
While trying to fix a problem last week I wanted to remove and recreate the PowerShell virtual directory, and I found the PowerShell command, but no working examples for the correct syntax.
Solution
1. Remember your Exchange Management Shell won’t work, so load the Windows Powershell Modules shell. (Note: You will find this one under Administrative tools, NOT the one on the taskbar).
2. To remove the PowerShell virtual directory from the default web site;
[box]
Remove-PowerShellVirtualDirectory “Powershell (Default Web Site)”
[/box]
