1

Set AdminSessionADSettings ViewEntireForest To True By Default

In Exchange 2010 the Set-AdServerSettings  cmdlet is used to manage the AD environment in the current Exchange Management Shell (EMS) session.  In Exchange 2007 there was a variable called AdminSessionADSettings  for the same purpose.  Exchange admins normally use the Set-AdServerSettings cmdlet to change a session’s view scope, so that they can see objects in multiple domains.  By default EMS places the focus on the local domain. 

This can become tedious if we have to change scope at the start of every EMS session. 

This was exactly the question posed during a recent workshop - How to set EMS so that it will default to the forest?

Please note: If any issues are caused by changes in the method outlined below, Microsoft support may request that the changes are removed since they are not officially tested or documented by the Exchange Product Group. You are also advised to document the initial settings so any change can be successfully reverted. 

While we are on the support topic, directly loading the Exchange 2010 and 2013 PowerShell snap-in is not supported except in very specific scenarios.  Those scenarios are documented in release notes and certain KB articles.  The snap-in should not be loaded directly, and a regular remote PowerShell must be used for all normal activities. 

PowerShell Profile Pandemonium

PowerShell does have the option to embed commands into the profile so that they are executed when PowerShell is started.  However if you try to add the Exchange 2010 Set-ADServerSettings cmdlet into the PowerShell profile you will receive an error stating that the cmdlet cannot be found.  This is since the remote PowerShell session has not been establish to make the Set-ADServerSetting cmdlet available.  Bit of a chicken and egg situation…

For completeness sake, this is what some folks will try to do and modify the PowerShell profile.  Please see here for more details on PowerShell profiles you can ask PowerShell by running:

Get-Help about_profiles | MORE

If we check the PowerShell $Profile variable, it shows the following location:

$Profile.PSExtended | Format-List

Examining Locations For The Different PowerShell Profile Files

Let’s modify the PowerShell profile that is referenced in the $Profile variable.  This is the one under the user’s documents folder and is the CurrentUserCurrentHost one listed above. 

Since the folder path does not fully exist, let’s create it and the file with the New-Item cmdlet specifying that it is of type “file”. 

Creating The PowerShell Profile File

Then Notepad will open up the file so that we can add the Set-ADServerSettings command.

Adding Set-AdServerSettings To PowerShell Profile

Finally we test expecting great results, but what do we see…..

Adding Set-AdServerSettings To PowerShell Profile Did Not Work Out So Well

Bah!  Time for plan ‘B’…. 

Before we move onto plan ‘B’ the above PowerShell profile file should be removed since it does not work.

Removing The PowerShell Profile File That Was Created

 

Plan B

If you view the properties of the Exchange Management Shell shortcut, there are some interesting properties contained within. 

Examining Exchange 2010 Management Shell Shortcut Properties

You should see something like so:

C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -version 2.0 -noexit -command ". 'C:Program FilesMicrosoftExchange ServerV14binRemoteExchange.ps1'; Connect-ExchangeServer -auto"

What does the above do?  PowerShell is started specifying the version and that it should not exit after completing the command.  The command to execute is the RemoteExchange.ps1 script that lives in the Bin Exchange directory.  Then there is the continuation character “;” so execution continues and calls one of the functions created by the Exchange scripts “Connect-ExchangeServer”.  As a side note it is these scripts that customise the EMS and provide the Get-ExBlog, Get-Tip and Connect-ExchangeServer functions.  

Do not modify the Exchange scripts that are signed.  What we can do is shim in an extra command into this shortcut.  Note that the syntax is a little demanding and that the script must be preceded with a “.” prior to the script name.

Let’s Make an additional Script called StartMeUp.ps1 and place this into the C:Scripts folder.  This is where the Contoso admins place all of their scripts.  Don’t you?  We will then call StartMeUp.ps1 when the EMS is started.  The properties of the EMS are adjusted like so:

C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -version 2.0 -noexit -command ". 'C:Program FilesMicrosoftExchange ServerV14binRemoteExchange.ps1'; Connect-ExchangeServer –auto; . ‘C:ScriptsStartMeUp.ps1’ "

Please note this is one line, though it may wrap. 

The contents of the StartMeUp.ps1 file are shown here for reference:

Set-AdServerSettings -ViewEntireForest $True

Write-Host
Write-Host

Write-Host "Hello Michael, this is KITT.  How are you doing today?" -ForeGroundColor magenta

Write-Host "Your current ADServerSettings are:"  -ForeGroundColor magenta

Get-AdserverSettings

Write-Host

 

 

When you then open up the Management Shell, now we automatically have the ViewEntireForest Set to $True without having to do anything!

Exchange Management Shell - Now With ViewEntireForest Set To True By Default And Bonus Magenta Text!

* - Can you guess what was one of my favourite television programmes from the past?

One thing to note.  If additional copies were made from the initial EMS shortcut (like a desktop shortcut or pinned to the taskbar) they will likely not have the additional script embedded within them.  You may have to delete and then re-pin to the taskbar.

Hope this saves you one line of unnecessary typing every day!

 

Cheers,

Rhoderick

* – Bonus points if you can remember the name of the bad prototype of this car!   Hint!

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *