Monday, June 30, 2014
Toss in Lync client in the mix and you will also see it communicating with EWS.
To get a complete list of what us using your Exchange servers EWS you have to look in the IIS-logs. Your buddy here is the good old logpaser which can be found here LogParser 2.2 download.
Copy the IIS logfiles you want to analyze into a folder of your choice. Start a command prompt and run:
"C:\Program Files (x86)\Log Parser 2.2\LogParser.exe" "SELECT cs(User-Agent) as UserAgent, count(*) as hits FROM "path to iis logfiles" WHERE cs-uri-stem LIKE '/EWS/Exchange.asmx' AND cs-username GROUP BY UserAgent" –I:IISW3C
Output will show the UserAgent and number of corresponding hits.
You can add “-O:tsv > outputfilename.txt” at the end of the logparser query to save the output in a tab separated text file for easier reading.
You can also run the logparser query in LogParserStudio. You see here that there is a number of different clients using EWs and they also have different patch levels. UserAgent OC/15 is Lync 2013 client and OC/4 is Lync 2010 client.
ExchangeServicesClient is an appl. made by EWS managed API.
You might also find other UserAgents in there such as “Sipe/1.18.2” or “Evolution/3.10.2”.
You might want to stop them from accessing EWS, how is this done?
If you have configured your LoadBalancer to do Layer 7 inspection you probably could stop these UserAgents but a much easier way is to do this.
Configure some properties on the Organization object.
First have a look of current and default configuration. We see here that by default everyone is allowed to communicate with EWS
Get-OrganizationConfig | fl EWS*
How do you stop certain clients or only allow some?
Set the EwsApplicationAccessPolicy parameter to either EnforceAllowList or EnforceBlockList and then us the EwsBlockList or EwsAllowList which is an array of UserAgent (case sensitive) of the applications. You must also set the Enable EwsEnabled parameter to true to get this to work.
So there is actually a way to allow only certain applications to communicate with EWS. have a look at the Set-OrganizationConfig cmdlet http://technet.microsoft.com/en-us/library/aa997443(v=exchg.150).aspx
Saturday, May 31, 2014
Your Exchange 2013 server was just installed and you thought everything should look nice and shiny. But after you install SCOM management pack and start to collect information from Exchange servers you notice that many things is flagged as unhealthy.
You try the Exchange management cmdlet “Get-HealthReport <servername> and see some components show up as unhealthy. Not surprisingly it is the same things SCOM flags as unhealthy. SCOM management pack is totally different for Exchange 2013 than previous versions of Exchange. Previous version SCOM did a lot of testing to verify that Exchange was healthy. Now Exchange do this natively with Manages Exchange server health service, a.k.a. Managed Availability and SCOM is just reading the eventlog. Well it does more than just reading the eventlog but that’s not the scope for this article neither is the Managed Availability stuff except that it has Probes, Monitors and Responders.
Common things to show unhealthy are:
FEP: Forefront Endpoint Protection. Reason for this is that FEP is not installed on your server. You can of course install FEP on the server. if you do, carefully exclude processes/folders otherwise FEP will interfere with Exchange and possibly destroy functionality. Anti-Virus Software in the Operating System on Exchange Servers.
If you don’t want to install FEP you can make the unhealthy status go away in two ways. Edit the FEPActiveMonitoringContext.xml file and set the Enabled parameter to False. File is located in Exchange installation directory\bin\monitoring\config. You can also configure a MonitoringOverride with Add-ServerMonitoringOverride cmdlet. You can either create an override that’s last for up to 60 days or by version. Here is the command for creating an override by version.
Add-GlobalMonitoringOverride -Item Monitor -Identity "FEP\MaintenanceFailureMonitor.FEP" –PropertyName Enabled -PropertyValue 0 –ApplyVersion 15.0.847.32
Version can be found by running
Get-ExchangeServer e15-ex3 | fl AdminDisplayVersion
Versoin 15.0.847.32 happens to be Exchange 2013 SP1.
Identity is found with
Get-MonitoringItemIdentity -Identity FEP –Server <servername> | ft Identity,ItemType,TargetResource
it will produce a list of stuff related to FEP and it’s the monitor you would like to an override on, hence the Identity “FEP\MaintenanceFailureMonitor.FEP” in the overridemonitoring command.
When you have created the override monitor for FEP you should see the unhealthy status go away after a few minutes.
One of the most common reason for CASproxies to show up as unhealthy is that you’re using Basic auth only on the virtual directories. Reason for this is often that you’re using a reverseproxy that do authentication and authenticate to Exchange with basic auth.
configure your virtual directories to allow windows integrated or FBA. Seems like the probe only cannot use Basic authentication. Note. This seems to be fixed in the just released CU5 for Exchange 2013.
You could also create a GlobalMonitoringOverride as you did for FEP.
There is of course several other things that could end up being flagged as unhealthy but use the Eventlog and look into the crimson channel logs and Get-MonitoringItemIdentity to get more information whats wrong. Perhaps there is a real problem or just something that you need to do correct with an override
I recommend doing override with the version parameter because you don’t know what happens in the next Cumulative Update for Exchange. In the case with CASproxy’s it seems that Microsoft has correct the probe to also use Basic Authentication.
Remember though that when applying upcomgin CU you probably need to create new monitoringoverrides that match the new version.
Monday, April 14, 2014
If you haven’t created a SPF record to protect your SMPT domain on Internet this is for you.
SPF is not a single thing , it is two things. One thing is to verify incoming mail to your servers that they originate from a list of trusted servers. an example would be when your serves receive a mail that claims to be from domain.com , your server will do a lookup in DNS for information (the SPF record). This info will (if existing) have list of servers that are authorized to send mail with sender with SMTP address in domain.com domain. next step is for the receiving server to verify this SPF info together with header info in mail message and IP address of the sending server, if everything is OK it server will simply accept the email but if there is mismatch you have to decide and configure your server what to do, perhaps let email through anyway or mark it as spam.
The other thing is to create your own SPF record for others to verify mail claiming to come from your SMTP address space.
Easiest way to create your SPF record is to use one of the multiple wizards on Internet. Microsoft also has one https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ which is quite good. Remember that no wizard will never provide you with good results unless you enter good information into it so next step is to find all servers that send SMTP mail with senders from the SMTP domain you want to edit the SPF record for, this is key for a proper working SPF deployment.
SPF record itself is a plain TXT record in the zone authoritative for the SMTP domain and you can enter information in a variety of ways, IP addresses, server name, MX or a combination of them.
some examples of SPF records in domain.com zone.
v=spf1 ip4:10.10.10.10 ~all
This means that only a server with IP 10.10.10.10 is allowed to send mail with senders addresses in domain.com zone.
v=spf1 mx ~all
only servers listed in the MX record are allowed
v=spf1 a mx ip4:10.10.10.10 ~all
Only servers with A records or MX records or IP equal to 10.10.10.10 is allowed
The all parameter:
all parameter in SPF is prefixed with different chars such as – ~ ? +
- means that the information must match, it is otherwise illegal.
~ means that it should match but could also mismatch.
+ means that it is absolutely fine for other servers than listed to send email for domain.com
? means either way, it may or may not originate from the servers specified.
Sometimes you need to let someone else deliver mail for your domain such as news mail sent from a provider or perhaps you have configured your Exchange in a hybrid setup with some users on on premise and some in Office 365. you can of course simply add the providers IP addresses to your SPF record but this impractical because could change without you knowing and they could also be multiple causing the SPF syntax to be invalid.
Why would SPF be invalid when you have a lot of information in it?
the RFC states that the receiving server must be able to figure out each SPF record with 10 or less NS queries.
solution for outsourced email or many NS queries is to use the include parameter.
v=spf1 mx include:provider.net ~all
this means either mail are authorized to come from servers listed as MX or whatever the spf record says in the provider.net zone. With this technique you can manage your servers and the provider can manage their environment independent and also making the verifying server only do 2 NS queries. first for your MX records and the other one for the SPF record in provider.net zone, now there is a new spf record giving us 10 additional queries to use.
Good practice in my opinion.
Collect information about all system that could send mail for domain.com.
Start with ?all parameter and try to log what’s happening. by logging I mean log what NS queries is done against the domain.com zone. this is a lot easier if you run and manage the NS hosting the domain.com zone than if it outsourced to a provider which might not be that helpful with statistics.
Don’t change to –all unless you are very sure that the spf record is correct.
Don’t use your production domain for bulk marketing mail, create a separate domain for this because if something goes wrong, only the marketing stuff will fail.
Verify your SPF syntax, here is on tool that can be used http://www.kitterman.com/spf/validate.html
If you have a lot of info in your SPF, use the include parameter.
Verify incoming email to your environment
make Exchange verify incoming email.
Install the ant spam agents which is already deployed if you’re using Edge. configure the SenderID transport agent.
Configure it with appropriate action.
Set-SenderIdConfig -SpoofedDomainAction StampStatus
spoofedDomainAction could be Delete, Reject of StampStatus. StampStatus is interesting since it will allow mail to be received but Exchange will stamp it and later in the transport pipeline the content filtering agent will consider this stamping and most likely classify the email as more likely to be spam.
Last, enable the SenderID agent with Set-SenderIdConfig -Enabled $true
The senderID agent has some other good to know configuration parameters. BypassedRecipients and BypassedSenderDomains which is self explainatory, there is also TempErrorAction which also has the Delete,Reject, StampStatus values.
TempErrorAction happens when the verifying server encountered a transient error while checking the SPF, perhaps the spf syntax is incorrect, perhaps NS query timed out or something else that wasn’t considered to be normal.
Be safe and publish spf info in your DNS about your smtp domains and enable checking of the spf for incoming mail to your servers.
Tuesday, March 11, 2014
Microsoft some time ago published some information about modern public folder limitations in this TechNet article describing for example that you are only supported if you have less than 100 public folder mailboxes or no more than 10.000 folders.
Question is what you do when you have more than the limits mentioned? delete some, move some stuff to other solutions, don’t migrate to Exchange 2013 or at least do not migrate your public folders to 2013. None of the above don’t sound that appealing if you have decided to go for 2013. Easiest would be to leave public folders on your older Exchange but that has drawbacks as well such as not being able to enable Kerberos authentication or mapi/http. Exchange also behave a little strange sometimes when you’re using both Exchange 2013 and earlier version together.
Tuesday, February 25, 2014
Exchange 2013 Service Pack 1 which is essentially CU4 but is named SP1 instead. it contains some new functionality such more DLP functionality and the big one, support for Windows Server 2012 R2 Domain Controllers, raising both Domain Function and Forest Functional Level to 2012R2, and installing Exchange 2013 SP1 on Windows 2012 R2.
Other new stuff is that Edge server is back. A new protocol used for client/server communication is introduced called MAPI/HTTP which is very similar to MAPI over RPC which is then tunneled over HTTP so in short, communication don’t rely on RPC layer which gives some advantages when it comes to authentication and reconnection of clients. It is disabled by default and you also need Outlook 2013 SP1 for leverage MAPI/HTTP.
If you use TMG or any other reverseproxy that filter on URL’s you need to add ‘/mapi/*’ as an allowed URL.
As usual there is the regular schema and AD prep stuff to do before you install the first SP1 server.