Windows 2012 shortcuts

As much as I like Windows Server 2012 I also dislike the logoff/reboot/restart functionality because the are very hard to do when you use remote desktop to your server, fiddling with your mouse in the corners trying to get something to click on.

Thinking about this I searched Internet and discovered this: http://gallery.technet.microsoft.com/scriptcenter/Create-a-ShutdownRestartLog-37c8111d which is fine. I took this script and did some small adjustment  (adding Windows Update and shortcuts to desktop)

Get the script DesktopLinks.ps1

Another version 2 update again

Exchange has a long history of being a solid product, of course it has been bugs in it but they have been addressed with patches and service packs. But the last year or two the set has changed, who doesn’t remember the series of version 2 UR for Exchange 2010 SP about two years ago. My thinking of this is that Microsoft has changed focus from delivering Exchange as regular product with a roadmap of looking forward to a service pack that has a set number of bug-fixes and features. With the service in mind this is not the case to the same extent but rather that the service has become a living thing that constantly are patched and upgraded. With this approach, developers are constantly tossing in new fixes and functionality that sometimes break something else. One reason for this could be that Microsoft is trying to introduce a new feature or fix a problem really fast which is good but it looks like Microsoft is more focused on speed instead of quality it might also be that Microsoft trust and rely on the Managed Availability not to fix the problem but restore functionality for the end-user.
Both myself and customer that for some years now has been comfortable with applying patches as they comes out of Redmond compared to what was the case 15 years ago when patching was something that wasn’t that common. This fear of patching is now back in the Exchange world because of the rollups and CU’s that correct some stuff but also introduce others. Of course the message is to try patches in your lab, but to be honest who has time and can spend money on a lab that mimics your production system? Labs are almost every time smaller and you cannot try everything users do in production. With this several of my customers has now taken a step back and not applying Exchange patches as fast as they would like because of fear breaking things.
Nevertheless Microsoft has now release a version 2 of Exchange 2013 RTM CU2. It mainly addresses the problem with mail enabled Public Folder permissions introduced in CU2 http://blogs.technet.com/b/exchange/archive/2013/07/12/e2013-rtm-cu2-issue-public-folder-permissions-loss-after-pf-mailbox-move.aspx.
The new version 2 of CU has build 712.24 compared to the CU2 712.22. If you already have deployed CU2 you can simply run “setup.exe /m:upgrade /IAcceptExchangeServerLicenseTerms” to install CU2v2.
Download link Exchange 2010 RTM CU2 ver 2 and look on the details to see that you download the correct CU2.
Read Microsoft Exchange team announcement http://blogs.technet.com/b/exchange/archive/2013/07/29/now-available-updated-release-of-exchange-2013-rtm-cu2.aspx

RBL and Exchange 2013

When you install the Antispam agents on Exchange 2013 servers you get all of them installed like you did for previous versions of Exchange server. most of them will get installed on the mailbox role but not the Connection filtering agent aka. RBL, DNS Block List etc.

The powershell script: install-AntispamAgents.ps1 will look for which server role is installed and will not install Connection filtering if the server hold the mailbox role. This is understandable since SMTP connection should come in from the CAS server and then the original sending IP will not be show since CAS do Source-NAT. So the logic would be to install the connection filtering agent on CAS but the install script will not let you do that either. Connection Filtering will only install on Edge role.

I can only speculate why this is, but either Microsoft want it to be like this or they have found some trouble with the Connection Filtering Agent running on CAS.

I figured I will give this a try anyway, and here is how you get it to work.

Start Exchange Management Shell as administrator.

Change Directory to scripts folder.
cd $exscripts

Install the agent.
Install-TransportAgent -Name "Connection Filtering Agent" -TransportService FrontEnd -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.ConnectionFiltering.ConnectionFilteringAgentFactory" -AssemblyPath "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\Hygiene\Microsoft.Exchange.Transport.Agent.Hygiene.dll"

If you have multiple agents running on the frontend transport you must set them in the correct order with the priority parameter

Add a IPBlocklistprovider of your choice
Add-IPBlockListProvider -Name zen.spamhaus.org -LookupDomain zen.spamhaus.org -AnyMatch $true -Enabled $true

You can add more than one provider if you like. If you Don’t provide a custom response it will be “Recipient not authorized, your IP has been found on a block list”

Enable the agent
Enable-TransportAgent -TransportService FrontEnd -Identity "Connection Filtering Agent"

Restart FrontEnd transport service
Restart-Service MSExchangeFrontEndTransport

Now the agent should be live and kicking. Logging for the frontend agent is here “C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\AgentLog” instead of the directory for the backend transport “C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\AgentLog”

Since the script don’t install the Connection filtering agent on CAS it is probably unsupported to install the agent manually, but I had it running for months without any problem so make your own judgment.

Exchange 2013 Admin Center URL’s

You have just installed Exchange 2013 in your Exchange 2007 or 2010 organization. You start a browser to access the Exchange Admin Center, the Exchange GUI admin tool, point the browser to https://servername/ecp and login with an account you know have permission in Exchange but are prompted with an error message.
Reason for this is that the mailbox you try to logon to is not located on Exchange 2013. solution is to move the mailbox to Exchange 2013 mailbox server or change the URL to “https://casservername/ecp?ExchClientVer=15”. This will tell EAC to show the Exchange 15 version of EAC instead of the Exchange 14 version which should be shown because the mailbox is not located on Exchange 15 server.
With the new URL you get into EAC and can start configure your Exchange 2013 server and life is good until you realize that EAC will be reachable from Internet. It will still require authentication, but nevertheless, reachable.
Since you have TMG to publish Exchange with you figure that you can deny access to /ecp URL from Internet but this will unfortunately stop users from accessing the OWA options web.

You find out that there is a parameter “AdminEnabled” on the ECP website to disable EAC. By setting AdminEnabled to False. Sadly this option disable EAC completely and you now only have the Exchange Management Shell to use and most people want a GUI to manage Exchange.

Solution is to create a new website that is not reachable from Internet but only from Internal network. Easiest is to change the listening port on the new website.

here is what you need to do.

# port used for the EAC website
$port = 9443

# create a new folder to host the new website
mkdir C:\EAC

# create a new webiste
New-Website -Name EAC -PhysicalPath C:\EAC -Verbose -Ssl -Port $port -Id $Port –ApplicationPool MSExchangeOWAAppPool

Then you must assign a certificate to the website. This can be done on the bindings option on the newly created EAC website options.

#create FW rule to allow traffic to website
New-NetFirewallRule -Name "EAC website" -Description "Exchange Admin Center website" -DisplayName "EAC website" -Protocol TCP -Profile Any  -Action Allow -LocalPort $port 

and then create the ECP applications in the EAC website.

#hostname
$hostname = ([System.Net.Dns]::GetHostByName(($env:computerName))).hostname

#InternalUrl
$IntUrl = (Get-EcpVirtualDirectory -Server $hostname).InternalUrl.tostring()

# Get path from the original ECP website
$DirPath = (Get-EcpVirtualDirectory -Server $hostname).path

# Create new EAC web
New-EcpVirtualDirectory -WebSiteName EAC -Server $hostname -InternalUrl $IntUrl -Path $DirPath -Role ClientAccess -AppPoolId MSExchangeECPAppPool

# Finally , diable EAC on the default ECP app
Set-EcpVirtualDirectory $hostname\'ecp (default web site)' -AdminEnabled $false

New-ECPVirtualDirectory states that you must create a OWA application also, but I have not encountered any problem by not doing this. The only problem I have when doing this is that browsing in the OU structure in AD when creating new mailboxes don’t work. have tried both with the above settings and also by creating the OWA appl. as suggested but it simplyu don’t work either way.
Simply put the commands in a powershell script and run it from EMS. when done you can access EAC with the new URL “https://casname:9443/ecp”.
Tips: when later changing URL and certificate on your CAS, you should also change them in the EAC website to make everything work correctly.

This is most likely unsupported but I have it running for several months without any problem except for the browsing thing in EAC.

Irrational behavior of Exchange 2013 receive connectors

Scenario: Exchange 2013 server with both mailbox and client access role combined.
You create a receive connector and scope it down to some specific IP addresses for applications running on servers with the specified IP. You configure to allow anonymous relay on the connector.

Applications on server are happy since they can now anonymously submit and relay messages off your Exchange installation to Internet.

Suddenly after a few hours, applications cannot send and relay mail.
Luckily you have protocol logging enabled and discover that your newly created connector is not used anymore. some more troubleshooting later and you desperately restart Exchange transport service. After the restart mail flow is restored the way you want.

But again after some hours, mail flow stops. further investigation shows that exactly the same thing has happened again, another restart of Exchange transport get things going.

Solution: Restart the transport service with a few hours interval, nahh don’t think so. Exchange 2013 is brand new and should work, and before the migration you had the exact configuration with Exchange 2010 server.

Real solution: I very simple. remove the old receive connector and create a new one, but connect it against the frontend transport instead of the default Hub transport (backend).
Transport system has been running fine as it should for a couple of weeks now. I believe this is a bug in the transport service and the symptom is selecting the wrong receive connector when there is an incoming connection to Exchange.

It makes sense to connect receive connectors and possibly send connectors against frontend (CAS server) but I think it should work equally fine if you select the backend (mailbox server) especially when the backend is the default option when using Exchange Admin Center.