RPC virtual Directory Basic Authentication keeps getting disabled

RPC virtual Directory Basic Authentication keeps getting disabled

A common problem, and i always keep forgetting how to fix it again:

The RPC virtual Directory Basic Authentication keeps getting disabled in about 5 minutes even when we enable it manually. During the testing of the RPC/HTTP via http://exrca.com/, it keeps passed when the Basic Authentication keeps enabled and failed when the change has introduced automatically.

Also, the cmdlet output for Get-OutlookAnywhere |fl showed the IISAuthenticationMethods as follows:



So the Exchange was forcefully overwriting the Windows IIS settings for RPC virtual Directory with on some minutes every time.

Requirement:
Default Settings for Exchange Virtual Directories for Exchange 2010 & 2013 showed the following requirement for RPC Virtual Directory under ‘Default Website’ in IIS.



Also IISAuthenticationMethods for OutlookAnywhere should be listed as follows:



How to Fix the issue
The TechNet Blog published here mentioned some hints to fix the issue.
The fix is set the Exchange OutlookAnywhere settings forcefully by using the following cmdlet:

Get-OutlookAnywhere | Set-OutlookAnywhere -IISAuthenticationMethods: Basic, ntlm

After setting this, I have manually Enabled the RPC virtual Directory Basic Authentication and it keeps maintaining the settings because of the fix.

Source

Force Lync sync, updating Lync contacts

Lync in combination with sharepoint sometimes doesn't update the profile picture.
To force the update process which by default runs at 1:30 at night, you can run:

Update-CsAddressBook

and/or:

Update-CsUserDatabase

To check the current settings:

Get-CsUserReplicatorConfiguration


Identity                  : Global
ADDomainNamingContextList : {}

ReplicationCycleInterval  : 00:01:00

and:

Get-CsAddressBookConfiguration

Identity                   : Global

RunTimeOfDay               : 1:30

KeepDuration               : 30

SynchronizePollingInterval : 00:05:00

MaxDeltaFileSizePercentage : 20

UseNormalizationRules      : True

IgnoreGenericRules         : False

EnableFileGeneration       : True

Great trouble shooting can be found here:

Source part 1

Source part 2

Source part 3

Automapping of Mailbox in Outlook does not work if Full Access Permission are assigned to a Group

Came across this blogpost when searching for a similar problem i had.
Turns out the attributes in AD for the group are not updated.

But there's a script for that:

INFORMATION
Many companies may have a number of shared mailboxes that their users or certain departments may require access to. Generally the easiest way to get this done based on Microsoft methodology is to add the individual users to a group and give the group permission to the resource – all nice so far!
One of the new improvements of Exchange 2010 SP1 was the possibility of an Outlook client to automatically map to its profile any mailbox that the logged on user has full access to!

SO HOW DOES IT WORK??
When you assign a user full access permission permissions in Exchange 2010 SP1 to a shared mailbox, Exchange will modify the multi-valued MsExchDelegateListLink attribute on the shared mailbox to include the distinguished name (DN) of the users who have been assigned the access permission.
At the same time, Exchange will not update the MsExchDelegateListBL attribute on each of the users who have been given the permission to include the DN of the shared mailbox. Next time the user opens Outlook, it will use AutoDiscover to locate the values of the MsExchDelegateListBL for the user and use it to automatically map the shared mailbox to the user’s Outlook profile.
This works perfect if you are assigning individual users the permission but many organizations use groups to assign such permissions. When a group is assigned this permission, all the members of the group will inherit the rights assigned HOWEVER Automapping will NOT work! This is because the group’s MsExchDelegateListLink attribute is modified and not the individual users within the group.

WORKAROUNDS

1. Users will be able to add the shared mailbox manually by adding it to their Outlook profile.
2. Use the following Exchange Powershell script that will read the membership of the distribution group and add each individual member to have full access permission to the shared mailbox (copy the code below and paste to a notepad file. Save the file with a NAME.PS1 extension):

$DL = Get-distributiongroupmember GROUPNAME | Select-Object -ExpandProperty Name
foreach ($D in $DL ) {
Add-MailboxPermission -Identity SHARED_MAILBOX_NAME -User $D -AccessRights ‘FullAccess’
write-host -FORE yellow “$D is a member of the distribution group GROUPNAME has been given full access permission to SHARED_MAILBOX_NAME mailbox” }

Please name sure to replace GROUPNAME with the name of the distribution group and SHARED_MAILBOX_NAME with the name of the shared mailbox

Source

Allow Anonymous Relay on a Receive Connector

One of those things you do once a year and think, how did i do that the last time?

Set up your receive connector:

Use the EMC to create the Receive connector

---

1. Perform one of the following steps:
   
   1. To create a Receive connector on a computer that has the Edge Transport server role installed, select Edge Transport, and then in the work pane, click the Receive Connectors tab.
   2. To create a Receive connector on a Hub Transport server role, in the console tree, expand Server Configuration and select Hub Transport. In the result pane, select the server on which you want to create the connector, and then click the Receive Connectors tab.
2. In the action pane, click New Receive Connector. The New Receive Connector wizard starts.
3. On the Introduction page, follow these steps:
   
   1. In the Name field, type a meaningful name for this connector. This name is used to identify the connector.
   2. In the Select the intended use for this Receive connector field, select Custom.
   3. Click Next.
4. On the Local Network settings page, follow these steps:
   
   1. Select the existing All Available IPv4 entry, and then click .
   2. Click Add. In the Add Receive Connector Binding dialog box, select Specify an IP address. Type an IP address assigned to a network adapter on the local server that's best able to communicate with the remote messaging server. In the Port field, type 25, and then click OK. Leave the Specify the FQDN this connector will provide in response to HELO or EHLO field blank.
   3. Click Next.
5. On the Remote Network settings page, follow these steps:
   
   1. Select the existing 0.0.0.0 - 255.255.255.255 entry, and then click .
   2. Click Add or the drop-down arrow located next to Add and type the IP address or IP address range for the remote messaging server or servers that are allowed to relay mail on this server. When you're finished entering the IP addresses, click OK.
   3. Click Next.
6. On the New Connector page, review the configuration summary for the connector. If you want to modify the settings, click Back. To create the Receive connector by using the settings in the configuration summary, click New.
7. On the Completion page, click Finish.
8. In the work pane, select the Receive connector that you created.
9. Under the name of the Receive connector in the action pane, click Properties to open the Properties page.
10. Click the Permission Groups tab. Select Anonymous users.
11. Click OK to save your changes and exit the Properties page.

Use the Shell to create the Receive connector

---

This example uses the New-ReceiveConnector cmdlet to create the Receive connector Anonymous Relay that listens on local IP address 10.2.3.4 on port 25 from a source server at IP address 192.168.5.77.

Copy

New-ReceiveConnector -Name "Anonymous Relay" -Usage Custom -PermissionGroups AnonymousUsers -Bindings 10.2.3.4:25 -RemoteIpRanges 192.168.5.77

For detailed syntax and configuration information, see New-ReceiveConnector.

Use the Shell to grant relay permission to anonymous connections on the new Receive connector

---

Note:
You can't use the EMC to perform this task.

This example retrieves the specified Receive connector information and pipes the result to the Add-ADPermission cmdlet to grant relay permission to anonymous connections on the new Receive connector.

Copy

Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

For detailed syntax and configuration information, see Get-ReceiveConnector or Add-ADPermission.

Use the EMC to create the Receive connector as externally secured

---

1. Perform one of the following steps:
   
   1. To create a Receive connector on a computer that has the Edge Transport server role installed, select Edge Transport, and then in the work pane, click the Receive Connectors tab.
   2. To create a Receive connector on a Hub Transport server role, in the console tree, expand Server Configuration and select Hub Transport. In the result pane, select the server on which you want to create the connector, and then click the Receive Connectors tab.
2. In the action pane, click New Receive Connector. The New Receive Connector wizard starts.
3. On the Introduction page, follow these steps:
   
   1. In the Name field, type a meaningful name for this connector. This name is used to identify the connector.
   2. In the Select the intended use for this Receive connector field, select Custom.
   3. Click Next.
4. On the Local Network settings page, follow these steps:
   
   1. Select the existing All Available entry, and then click .
   2. Click Add. In the Add Receive Connector Binding dialog box, select Specify an IP address. Type an IP address assigned to a network adapter on the local server that's best able to communicate with the remote messaging server. In the Port field, type 25, and then click OK. Leave the Specify the FQDN this connector will provide in response to HELO or EHLO field blank.
   3. Click Next.
5. On the Remote Network settings page, follow these steps:
   
   1. Select the existing 0.0.0.0 - 255.255.255.255 entry, and then click .
   2. Click Add or the drop-down arrow located next to Add and type the IP address or IP address range for the remote messaging server or servers that are allowed to relay mail on this server. When you're finished entering the IP addresses, click OK.
   3. Click Next.
6. On the New Connector page, review the configuration summary for the connector. If you want to modify the settings, click Back. To create the Receive connector by using the settings in the configuration summary, click New.
7. On the Completion page, click Finish.
8. In the work pane, select the Receive connector that you created.
9. Under the name of the Receive connector in the action pane, click Properties to open the Properties page.
10. Click the Permission Groups tab. Select Exchange servers.
11. Click the Authentication tab. Select Externally Secured (for example, with IPsec).
12. Click OK to save your changes and exit the Properties page.

Use the Shell to create the Receive connector as externally secured

---

This example creates the Receive connector Anonymous Relay that listens on local IP address 10.2.3.4 on port 25 from a source server at IP address 192.168.5.77.

Copy

New-ReceiveConnector -Name "Anonymous Relay" -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers -Bindings 10.2.3.4:25 -RemoteIpRanges 192.168.5.77

For detailed syntax and configuration information, see New-ReceiveConnector.

Source

When a database failover occurs, send an email on event id

When a database failover occurs you normally wouldn't know unless you have a monitoring like SCOM setup.
In our case we don't have any kind of monitoring going on, but i do want to know if a failover occurs.

To do this we can use the great new feature of the eventviewer: "Attach task to this event".
The events you're looking for are:

127
147
161
184
184
252
292
293
301
316
333

After filtering the eventlog in: applications and services logs - microsoft - exchange - high availability - operational filter the log on warnings, errors, and critical events, you can see all failover related event id's.

Select an event and click "Attach task to this event".

Select "Send an e-mail"

Fill out with your settings

On the summary page you can select "Open the properties dialog for this task when i click finish", this allows you to change the account the the task uses to run.

After you click finish the task can be found at "event viewer tasks"

When any of these events occurs, you will be notified.

You will have to do this for every event you want to monitor.

Increase cluster time out values, database failover's too soon

If your exchange databases fail over too soon, you can alter the default values for the cluster service.

First check your default values:
In a command window on a database server run:

cluster /prop

T  Cluster              Name                           Value
-- -------------------- ------------------------------ -----------------------
DR CL-XXXXX             FixQuorum                      0 (0x0)
DR CL-XXXXX             IgnorePersistentStateOnStartup 0 (0x0)
SR CL-XXXXX             SharedVolumesRoot              C:\ClusterStorage
D  CL-XXXXX             AddEvictDelay                  60 (0x3c)
D  CL-XXXXX             BackupInProgress               0 (0x0)
D  CL-XXXXX             ClusSvcHangTimeout             60 (0x3c)
D  CL-XXXXX             ClusSvcRegroupOpeningTimeout   5 (0x5)
D  CL-XXXXX             ClusSvcRegroupPruningTimeout   5 (0x5)
D  CL-XXXXX             ClusSvcRegroupStageTimeout     7 (0x7)
D  CL-XXXXX             ClusSvcRegroupTickInMilliseconds 300 (0x12c)
D  CL-XXXXX             ClusterGroupWaitDelay          30 (0x1e)
D  CL-XXXXX             ClusterLogLevel                3 (0x3)
D  CL-XXXXX             ClusterLogSize                 100 (0x64)
D  CL-XXXXX             CrossSubnetDelay               1000 (0x3e8)
D  CL-XXXXX             CrossSubnetThreshold           5 (0x5)
D  CL-XXXXX             DefaultNetworkRole             2 (0x2)
S  CL-XXXXX             Description
D  CL-XXXXX             EnableSharedVolumes            0 (0x0)
D  CL-XXXXX             HangRecoveryAction             3 (0x3)
D  CL-XXXXX             LogResourceControls            0 (0x0)
D  CL-XXXXX             PlumbAllCrossSubnetRoutes      0 (0x0)
D  CL-XXXXX             QuorumArbitrationTimeMax       90 (0x5a)
D  CL-XXXXX             RequestReplyTimeout            60 (0x3c)
D  CL-XXXXX             RootMemoryReserved             4294967295 (0xffffffff)
D  CL-XXXXX             SameSubnetDelay                2000 (0x7d0)
D  CL-XXXXX             SameSubnetThreshold            5 (0x5)
B  CL-XXXXX             Security Descriptor            01 00 04 80 ... (164 byte
s)
D  CL-XXXXX             SecurityLevel                  1 (0x1)
M  CL-XXXXX             SharedVolumeCompatibleFilters
M  CL-XXXXX             SharedVolumeIncompatibleFilters
D  CL-XXXXX             ShutdownTimeoutInMinutes       20 (0x14)
D  CL-XXXXX             WitnessDatabaseWriteTimeout    300 (0x12c)
D  CL-XXXXX             WitnessRestartInterval         15 (0xf)

To change the value for the internal network:

cluster /prop SameSubnetDelay=2000:DWORD

To change the valuea for the external network:

cluster /prop CrossSubnetDelay=4000:DWORD

To change the default value for the number of error's before failing over:

cluster /prop CrossSubnetThreshold=10:DWORD
cluster /prop SameSubnetThreshold=10:DWORD

These are the maximum values.
The command only need to be run on 1 Exchange database server

Source

To never forget

Get full computer model name for MDT:

wmic csproduct get name

wmic csproduct get vendor

Get active OWA sessions by email

Sometimes you have to know how many users are connected to your Outlook Web App.

I brew up some script to show you just that:

# Script: Get-OWASessions.ps1
# Purpose: Shows the users currently connected to OWA
# Author: Edwin van Brenk
# Date: 28-01-2014
# For:         Company

#Functions
$filename = "D:\Temp\OWASessions.html"
$date = get-date -Format dd-MM-yyyy 
$smtpServer = "smtp.company.lan"
$smtpFrom = "OWASessions@company.com"
$smtpTo = "username@company.com"
$messageSubject = "Active OWA Sessions $date"

Write-Host "Deleting temp file"
#If outputfile already exsists then delete
if (Test-Path($filename))
{
remove-item $filename
}

write-host "Getting OWA sessions please wait"
$htmlreport = Get-Mailbox -resultsize unlimited | Get-LogonStatistics | Where-Object {$_.ApplicationID -eq "Client=OWA"} | Select-Object UserName,LastAccessTime | ConvertTo-Html
Write-host "Creating output file"
$htmlreport | Out-File $filename
write-host "Getting ready to send the email"
$message = New-Object System.Net.Mail.MailMessage $smtpfrom, $smtpto
$message.Subject = $messageSubject
$message.IsBodyHTML = $true

$message.Body = ( $htmlreport | out-string )
$message.Body = $htmlreport
write-host "Sending email"
$smtp = New-Object Net.Mail.SmtpClient($smtpServer)
$smtp.Send($message)

Write-Host "Done"

Disabled Accounts and ActiveSync Devices Continuing to Sync

Came across this article wich shed's some light on why users can keep on sending and receiving email when their password is expired or the whole useraccount is disabled.

This means that when a user leaves your company, disabeling the useraccount just doesn't cut it.

Disabled Accounts and ActiveSync Devices Continuing to Sync

Recently, an issue that has been around for some time started generating a lot of renewed interest.  The issue I'm referring to is regarding Exchange users still having access for several hours after their AD Account has been disabled.  This post is Part I of II, discussing why this happens and best practices to properly deal with/cut off access to users as quickly as possible relating to ActiveSync.  In Part II, I  will discuss this issue as it relates to Outlook and OWA and the best practices on how to deal with them
The main issue of concern is that if a user is terminated and just their AD account is disabled (which is a fairly standard process for many companies), that once their AD account is disabled it’s believed that the user is now stopped from being able to access anything using Windows Authentication, such as Exchange).  However, that may not necessarily be true…especially with ActiveSync.  If we’re talking about a terminated employee who was “walked out the door” and you want to IMMEDIATELY stop them from being able to send/receive emails via an ActiveSync device and all you've done is disable their AD account, they may still be able to sync for some time and send emails that you don't want sent.  This can then open a whole slew of headaches.

Why Does This Happen?

The ability for ActiveSync to continue to work even though the user's AD Account has been disabled is because of several reasons.  One of the main reasons is due to the way ActiveSync keeps a connection open to the server to watch for new messages.  That connection has already authenticated and has been validated…so while the AD count may be disabled, all Exchange knows is that the user HAD rights to the mailbox and is continuing to use that connection.  Eventually, the “life” of that authentication expires and the user has to re-authenticate (which is all done transparent to the user) and if the account was disabled, the re-authentication will fail and the user will no longer be able to sync.  ActiveSync devices with their long heartbeat intervals and token cache can still allow access up to 24 hours after an AD account has been disabled.  This is also related to caching done by IIS and Exchange, which I will talk about more in Part II.  But, in summary, just disabling a user's AD account will likely not stop them from accessing Exchange for at least a couple of hours if not more.

Best Practices to Follow Regarding Disabling User Access

1. Before disabling the AD Account, you should do the following:

a. Trigger a remote wipe of the device - OPTIONAL

This may or may not be something you want to do depending on your company’s policies, if it’s a personal device, etc.  However, once the sync is stopped through other means the device cannot come in and get the Wipe Request, so this is one of the first things that should be done if your company deems it necessary.

b. In addition, implement a block of all their devices (if you didn't issue a remote wipe and/or their device doesn't support remote wipe, etc):

If using Exchange 2010/Office365:

Get information about the user and devices

Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs

Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID

Block all Devices for a user

Set-CASMailbox -Identity <user> -ActiveSyncBlockedDeviceIDs "<DeviceID_1>,<DeviceID_2>"

If using Exchange 2007:

Get information about the user and devices

Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs

Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID

Block all Devices for a user

Set-CASMailbox -Identity <user> -ActiveSyncAllowedDeviceIDs "BLOCKED"

(Note: The use of the string “BLOCKED” is to enter a string that does NOT match any device they may be using as setting this value will ONLY allow a device with that Device ID string to sync [which no real device would have the Device ID of “BLOCKED”] and all others to NOT be allowed to sync)

c. Disable ActiveSync:

Set-CASMailbox -Identity <user> -ActiveSyncEnabled $false

d. Disable the mailbox (at least temporarily) - OPTIONAL

Note: It’s understood that some companies leave the mailboxes enabled to receive email so that OOF/automatic responses can be generated or so that no emails to the address are not blocked.  If this is the case, it’s recommended that you disable the mailbox for approximately 30m-1h and then enable again.  This will allow time for the change to go into effect and stop allowing ActiveSync to access.  This solution is in lieu of ActiveSync disabling as outlined above.

2. Disable the AD account.

Do note, the above changes are NOT instantaneous!  It can take around 5-10 minutes for the ActiveSync device blocking to go into effect, and that’s from the time that the change is replicated to all the DC/GCs used.  Obviously, if you make the changes against a DC/GC in another site and it has to replicate to the Internet-facing Exchange site(s) more time is needed.  The other settings can take up to 20 minutes to go into effect due to caching.
You may ask why we recommend using –ActiveSyncBlockedDeviceIDs AND –ActiveSyncEnabled?  It’s because the check for ActiveSyncBlockedDeviceIDs is checked almost continuously, since that part of Exchange is designed around the premise that devices are added or removed regularly.  However, ActiveSyncEnabled’s setting is cached for up to 20 minutes and then may only be rechecked if IIS Token Caching has expired.

Best Practices to Follow Regarding Disabling User Access

Here are the best practices related to Outlook and OWA:

1. Before disabling the AD Account, you should do the following:
   1. Disable Web services for the mailbox:

For Exchange 2007:

Set-CASMailbox -Identity <user> -OwaEnabled $false

 For Exchange 2010:

Set-CASMailbox -Identity <user> -OwaEnabled $false

Set-CASMailbox -Identity <user> -EwsEnabled $false

Set-CASMailbox -Identity <user> -EwsEnabled $false

Set-CASMailbox -Identity <user> -EcpEnabled $false

1. Disable MAPI services:

For Exchange 2007:

Set-CASMailbox -Identity <user> -MapiEnabled $false

Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true

For Exchange 2010:

Set-CASMailbox -Identity <user> -MapiEnabled $false

Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true

Set-CASMailbox -Identity <user> -EwsAllowMacOutlook $false

Set-CASMailbox -Identity <user> -EwsAllowOutlook $false

1. Set Recipient Limits to 0

Set-Mailbox -Identity <user> -RecipientLimits 0

1. Disable the mailbox (at least temporarily) - OPTIONAL

Note: It’s understood that some companies leave the mailboxes enabled to receive email so that OOF/automatic responses can be generated or so that no emails to the address are not blocked.  If this is the case, it’s recommended that you disable the mailbox for approximately 30m-1h and then enable again.  This will allow time for the change to go into effect and stop allowing clients to access.  This solution is in lieu of disabling as outlined above.

1. Disable the AD account

Source:
Part 1
Part 2

After Exchange 2010 SP3 RU4 OWA & Active Sync are messed up

After installing Exchange 2010 SP3 RU4, webmail and Active sync stopped working.
External access to our webmail page was impossible.

Turns out that the update had made some configuration changes for us, THANKS!!! not
The hardware load balancer in our environment does SSL offloading.
So the SSL options in IIS are turned off.

The RU4 update however thought it was a good idea to turn on SSL for the default web site on both CAS-HUB servers. Result, no way to get in to the webmail and get active sync to work.

Turn the SSL off and a few minutes later we were good to go.

Once again, spank you Microsoft for undocumented features and making my free sunday even shorter.

A well back to the last 2 servers that need to be updated, I got some errors in those too, so I think in about an hour or so there will be another rant from me.