Showing posts with label Exchange 2007. Show all posts
Showing posts with label Exchange 2007. Show all posts

28 June 2019

Removing AccessRights - WARNING: An inherited access control entry has been specified and was ignored - WARNING: An inherited access control entry has been provided and was ignored

So this just happed:
Remove-MailboxPermission -Identity SharedMailboxAlias -User Username -AccessRights FullAccess -InheritanceType all
Confirm
Are you sure you want to perform this action?
Removing mailbox permission "SharedMailboxAlias" for user "UserName" with access rights "'FullAccess'".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
WARNING: An inherited access control entry has been specified: [Rights: CreateChild, Delete, `
ReadControl, WriteDacl, WriteOwner, ControlType: Allow]  and was ignored on object `
"CN=SharedMailboxAlias,OU=Shared Mailboxes,OU=Mail,DC=Domain,DC=lan".
Checked to see what was keeping me from removing the access rights:
Get-MailboxPermission -Identity SharedMailboxAlias -User UserName

Identity             User                 AccessRights                 IsInherited Deny
========             ====                 ============                 =========== ====
Domain.lan/Mail/S... Domain\UserName      {FullAccess}                 True        True
Domain.lan/Mail/S... Domain\UserName      {FullAccess}, Delete...      True        False
And there it was, the "IsInherited" value True.
So its coming from above...

So I had to go through and remove some legacy permissions from Exchange. This can be added at multiple levels so it’s aways a diagnostic trail to where this was added. Go through each of these and if IsInherited is set to False you’ve found out where it’s being applied from.
Get-MailBoxPermission Domain\UserName

Get-MailboxDatabase | Get-ADPermission -User Domain\UserName

Get-ExchangeServer | Get-ADPermission -User Domain\UserName

Get-OrganizationConfig | Get-ADPermission -User Domain\UserName
Remove the Permissions per level with
Get-MailBoxPermission Domain\UserName | Remove-ADPermission

Get-MailboxDatabase | Get-ADPermission -User Domain\UserName | Remove-ADPermission

Get-ExchangeServer | Get-ADPermission -User Domain\UserName | Remove-ADPermission

Get-OrganizationConfig | Get-ADPermission -User Domain\UserName | Remove-ADPermission
Some of the permissions where also added from AD.

Open up ADSI Edit and Navigate to these :

In “Default Naming Context” OU=Microsoft Exchange Security Groups,DC=Domain,DC=lan
In “Default Naming Context” CN=Microsoft Exchange System Objects
In “Configuration” CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=lan

Make sure the user is not in any of these.
After the User has been removed from any of these places its inheritance is gone is no longer listed.

07 December 2015

Brand OWA 2013 logon page

Just like in Exchange 2007 and 2010, the Outlook web app page can be customized to your needs.

See my previous post about this here.

In my organization we use 6 multi role Exchange 2013 servers, and when logging on to OWA you can't quickly see on which server you ended up.

This can be edited fairly quickly, but keep in mind that all these changes are undone when updating the Exchange systems with a cumulative update (CU).

First you need to go to the following location:
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
In there you will find a file called "logon.aspx", open it in your editor of choice.

For me that's Notepad++, and on line 272 add the following line:

<p><span style="color: #FFFFFF;">SERVERNAME</span></p>

This will add your servername in white text. So if you want to see it you'll have to select the entire logon page by pressing CTRL + a, then you will see the servername.



Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.
This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.


Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update. However, there are no guarantees that the file will not be changed by an update. If so, you will need to re-edit the logon.aspx file.

After each installation of a cumulative update for Exchange 2013, remember to execute both the UpdateCas.ps1 and UpdateConfigFiles.ps1 Windows PowerShell scripts.
It will save you a lot of trouble, troubleshooting errors with OWA and ECP.

02 July 2015

Hide your internal server names from email header

When sending email to an organization outside your lan you also send some information that you don't want to expose and even in some cases those emails are not accepted because the SPF rules state that no local domain names are accepted, as they cannot be resolved by reverse DNS checking the HELO.

One way of dealing with this issue is to remove the anonymous access right on the send connector:

Get-SendConnector “Connector Name” | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights ms-Exch-Send-Headers-Routing -user “NT AUTHORITY\Anonymous Logon”


In my opinion there's an easier way, one that can be rolled back instantly in case something goes wrong or causes errors.
Create a Transport rule that removes the "header" from all out going messages.


Open Microsoft Exchange Console
Navigate to:
Microsoft Exchange \ Organization Configuration \ Hub Transport \ Transport Rules





  • Right Click and select New Transport Rule 
  • Name it " Remove headers "Received" ” 
  • click Next
  • Choose "From users inside or outside the organization"
  • Select Inside click Next
  • Choose Remove header
  • As message header just write: "Received"
  • Click Next twice

02 April 2014

Convert Legacy mailbox to User mailbox

If you happen to have a Legacy Mailbox on an Exchange 2010 server, you can upgrade or convert it to a User Mailbox by using the shell command:

Set-Mailbox -identity Alias -ApplyMandatoryProperties


After executing the command, the mailbox should be converted from Legacy to user in about 20 seconds.

07 October 2013

Adding multiple Remote IP Addresses to existing Receive Connectors

I had to add a lot of ip addresses to our receive connector, but not overwrite the existing ip addresses in the receive connector.
For that I came across this excellent Powershell script that does just that:
<#
.DESCRIPTION
   Simple Powershell script that can bulk import remote IP ranges from a text file in a determined Exchange Receive Connector.
   The Import of the Remote IP ranges maintains the original values which are already present on the Selected Connector.
.PARAMETERS
   None - execute directly from the Exchange Management Shell
.Version
 0.1
.Author
 Andy Grogan
 http://www.telnetport25.com
.Compatibility
   Exchange 2007
   Exchange 2010
   Exchange 2013
.Release Date
 Jan 2013
#>

function Select-FileDialog 
{
      param([string]$Title,[string]$Directory,[string]$Filter="Text Files (*.txt)|*.txt")
      [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") | Out-Null
      $objForm = New-Object System.Windows.Forms.OpenFileDialog
      $objForm.InitialDirectory = $Directory
      $objForm.Filter = $Filter
      $objForm.Title = $Title
      $objForm.ShowHelp = $true
      
      $Show = $objForm.ShowDialog()
      
      if ($Show -eq "OK")
      {
            return $objForm.FileName
      }
      else
      {
            exit
      }
}

function get_RecConnector{

 $RecConns = Get-ReceiveConnector | Select -ExpandProperty Identity
 $Count = 0;
 Write-Host "Bulk Import of Remote IP Addresses for Exchange Receive Connectors" -ForegroundColor Green
 Write-Host "Version 0.1" -ForegroundColor Green
 Write-Host "www.telnetport25.com" -ForegroundColor Green
 Write-Host ""
 Write-Host "Detected Receive Connectors: " -ForegroundColor Cyan
 Write-Host ""
 foreach($Connector in $RecConns){
  Write-Host $Count "." $Connector -ForegroundColor White
  $Count ++
 }
 Write-Host ""
 $Choice = Read-Host "Please select the Receive Connector that you wish to work with."
 Write-Host ""
 import_RemoteIPRanges $RecConns[$Choice]
}

function import_RemoteIPRanges{

 param($ConnectorID)
 
 $FileName = Select-FileDialog "Open IP Range Text File..."
 $IPs = Get-Content $FileName
 
  foreach($IP in $IPs){
   Write-Host "Adding IP Address :" $IP " to "$ConnectorID -ForegroundColor Cyan
        $Rcnn = Get-ReceiveConnector "$ConnectorID"
        $Rcnn.RemoteIPRanges += $IP
        Set-ReceiveConnector "$ConnectorID" -RemoteIPRanges $Rcnn.RemoteIPRanges

  }
}

get_RecConnector
Write-Host ""
Write-Host "Script Completed." -ForegroundColor Yellow

Source

Export Receive connector RemoteIpRanges

Backing up your Receive connector RemoteIpRanges seem like a good idea, to me at least.
We currently have several hundred ip addresses added to our relay connector.

Losing all that work by some(ones) mistake would take a lot of work to recreate.

So here's how to do it:

First set your output higher, otherwise more than 16 ip addresses added to your connector will be truncated in the powershell output.
[PS] C:\>Get-ReceiveConnector "Relay Connector" | fl remoteipranges


RemoteIPRanges : {10.0.0.14, 10.0.0.20, 10.0.0.19, 10.0.0.18, 10.0.0.17, 10.0.0
                 .16, 10.0.0.15, 10.0.0.10, 10.0.0.9, 10.0.0.8, 10.0.0.7, 10.0.
                 0.6, 10.0.0.5, 10.0.0.4, 10.0.0.13, 10.0.0.12...}
As you can see the ...} at the end of the output means there's more than Powershell shows.

To unlimit the output for your current Powershell session:
$FormatEnumerationLimit =-1

Now we can list all the output to a file:
[PS] C:\>Get-ReceiveConnector "sr-XXXXX\smtp relay" | fl remoteipranges
 | out-file "d:\temp\smtp relay sr-XXXX.txt"
This file can be edited to your needs.
Source

08 February 2013

Brand OWA 2007 and 2010 with the Server Name

How to Brand OWA 2007, 2010 and 2013 with the Server Name
If your Exchange 2007 or Exchange 2010 and 2013 environment includes more that one CAS server, it's sometimes helpful to know which one a client is connecting to.  Environments with more that one CAS usually use some form of hardware or software load balancing, making it difficult to troubleshoot OWA issues.

A relatively easy way to do this is to brand each CAS server's OWA logon page with the server name.  This way, end-users are able to provide the server name if they run into problems.

For Exchange 2007, navigate to C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth folder and open the logon.aspx file using Notepad.

Add either of the two edits shown in the screenshot below:


Adding the server name as highlighted above in red will visibly add the server name to the logon screen, as shown below:



Adding the server name as highlighted above in blue will add the server name "invisibly" below the logon screen.  To view the server name, click anywhere on the screen and press CTRL-A to select all.  You can then see the server name, as shown below:


For Exchange 2010, navigate to the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth folder and open the logon.aspx file using Notepad.


Add the server name, as shown in the screenshot below:


This will add the server name to the logon screen, as shown below:


For Exchange 2013, navigate to the C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth folder and open the logon.aspx file using Notepad. In my example i used Notepad++ so you can see the line number.
On line 272 add: <p><span style="color: #ffffff;">servername</span></p>



Edit:
I added a personal touch to the 2010 option, at the very end of the logon.aspx page add the line:
<p><span style="color: #ffffff;">SERVERNAME</span></p>
This line will be invisible on the loginpage until you select ctrl + a.



Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.  This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.

Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update.  However, there are no guarantees that the file will not be changed by an update.  If so, you will need to re-edit the logon.aspx file.