AD Powershell cmdlets!
With the release of Windows Server 2008 R2, there will finally be native support for Active Directory management in Powershell. For those of us (myself included) who don’t/won’t use the third-party add-ins for AD, this is great news!
Check out the AD Powershell team’s blog: Active Directory Powershell Blog (easy enough name to remember) for more information and a downloadable cmdlet reference chart.
Thanks AD Powershell Team!
Activate SCR Target via EMS script
If you’ve got SCR installed and are using the Database Portability model described in “Standby Continuous Replication: Database Portability“, here’s a useful Exchange Management Shell that scripts the entire activation process. Just change all of the noted fields to match your source and target servers and even add additional storage groups/databases to the script if you like.
Be sure to triple check your entries and TEST IN A LAB ENVIRONMENT before unleashing this production!
Activate-SCRTarget.zip (1.6 KiB, 662 hits)
HOW TO: Configure and Start SCR Replication
It was a bit surprising to find that the TechNet documentation about configuring and starting SCR replication was…ah…less than perfect or easy to use. Here’s a simple set of commands you can use to get your SCR implementation rolling along nicely.
Before trying to configure SCR, be sure that your mailbox server has been configured properly first. That includes installing and configuring the Operating System and storage exactly the same as the SCR source (typically a CCR cluster). Here’s a few pointers:
- If you use volumes F, G, H, and I for two databases and two storage group logs…make sure you have that configuration on your SCR target.
- You should size the hardware identically to the SCR source, so use the same CPU type and speed, same amount of RAM, same server model, etc. where possible.
- Install Exchange using a custom setup and install the stand-alone mailbox server role.
- Leave the default mailbox storage and storage that Exchange setup installs, but be sure to remove the mailbox it created for you (if you were using an account without a mailbox). You’ll need these local mailboxes for Ops Mgr monitoring and routine testing purposes…just don’t create any real user mailboxes in them!
Here’s the commands you’ll need to run from the Exchange Management Shell to get things rolling:
Run from an Exchange server or management station on the same operating system version (although 32-bit or 64-bit does not matter) that does NOT have Exchange Server 2007 SP1 UR5 installed:
- Enable-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN-ReplayLagTime x.x:x:x -TruncationLagTime x.x:x:x
- Be sure to see the cmdlet notes to understand the implications of ReplayLagTime and TruncationLogTime. The values are in days.hours:minutes:seconds.
- If you ever need to change the values configured for ReplayLagTime or TruncationLogTime, you’ll have to disable the copy and enable it over again anew.
- Here’s the issue with UR5.
Run from the SCR target server, after verifying that Active Directory has replicated (especially critical when your SCR target server is located in a different AD Site):
- Suspend-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
- This cmdlet is usually not required, but it’s good practice to run. The SCR copy is configured and in a suspended state following the issuance of the Enable-StorageGroupCopy cmdlet.
- Update-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
- This gets the full copy (full reseed) started.
- Resume-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
- This cmdlet is usually not required, but it’s good practice to run. The SCR copy is resumed following the completion of the reseed.
To check the SCR replication status for all SCR instances on an SCR target server, issue the following command:
- Get-StorageGroupCopyStatus -Identity “SCR_source_server_name\*” -StandbyMachine SCR_target_server_name
TechNet cmdlet references:
- Enable-StorageGroupCopy
- Suspend-StorageGroupCopy
- Update-StorageGroupCopy
- Resume-StorageGroupCopy
- Get-StorageGroupCopyStatus
Exchange SSL certificates for IMAP and SMTP
If you’ve got an Exchange Server 2007 implementation, have you installed certificates for SMTP and IMAP (if you’ve enabled IMAP)? Exchange will generate self-signed certificates (good for one year), but you’d be better off putting your own certificates on to prevent client application errors related to invalid or expired certificates. Since IMAP is made available through the Client Access Servers, you can easily add an additional Subject Alternative Name (SAN) for IMAP, such as imap.mail.mycompany.com, to the Unified Communications certificate that you’ve already got installed to cover Outlook Web Access and Autodiscover.
If you’ve got the Hub Transport role on the same server, then you can easily add another SAN to the same certificate…otherwise, you’ll need another certificate for your Hub Transport servers. I’d recommend using a Unified Communications certificate here as well, so you can include both the individual server names and an alias such as smtp.mail.mycompany.com.
MS KB 929395 details the Unified Communications certificate providers that Microsoft has recognized. I’ve personally been using Digicert with great results. You can find some information about how to create the Exchange Server 2007 Unified Communications CSR here and how to install the certificate here.
Disabling Active Directory User Accounts, Part 2
As a followup to the Disabling Active Directory User Accounts, Part 1 post, here’s a Powershell script that will disable multiple accounts for you by using a CSV input file.
Scipt features:
- The username of the the administrator running the script is recorded in the text file that lists all of the groups the account was removed from.
- An email is automatically created and sent to the configured recipients (such as the AD Administrators group and/or Information Security…), which is fantastic from an end-to-end accountability and auditing point of view (who did it, when did they do it and why…)
- Disables the specified AD account
- Hides the mailbox from the Global Address List
- Removes the account from all groups it was a member of
- Creates a text file log of all groups the account was a member of
- Sets the password to be changed at the next login
- Sets the disable date in the “Title” field (an unused field in my organization)
Just find the following variables in the script and change them accordingly:
- $SourceFile = “\\MYSERVERPATH\account_disables_input.csv”
- This is the full UNC path to the CSV input file
- $EmailReportFile = \\MYSERVERPATH\Account_Disables_Report.txt
- This is the full UNC path to where you want the report saved (this is what is emailed out)
- $domain = “LDAP://dc=DOMAIN,dc=local”
- The LDAP bind URL for your domain…
- $To = “someone@mycompany.com”
- SMTP addresses, comma seperated, of who you want the report emailed to
- $SmtpClient.host = “smtp.mail.mycompany.com”
- The SMTP host name to handle your email report (your Exchagne 2007 Hub Transport server(s) or Exchange 2003/2000 front-end server(s) typically, make sure you can perform anonymous relay internally though….)
Download the script here…
Disable-ADAccountsMultiple.zip (3.2 KiB, 1,315 hits)
UPDATED Disable AD Accounts with Powershell
As a followup to the disabling AD accounts post earlier this month, I’ve updated the Power Shell (requires the Exchange Management Shell) script some to add some additional functionality.
New features:
- The username of the the administrator running the script is recorded in the text file that lists all of the groups the account was removed from.
- An email is automatically created and sent to the configured recipients (such as the AD Administrators group and/or Information Security…), which is fantastic from an end-to-end accountability and auditing point of view (who did it, when did they do it and why…)
Just find the following variables in the script and change them accordingly:
- $EmailReportFile = “\\YOUR_SERVER_PATH_HERE\Account_Disables_Report.txt”
- This is the full UNC path to where you want the report saved (this is what is emailed out)
- $domain = “LDAP://dc=DOMAIN,dc=local”
- The LDAP bind URL for your domain…
- $To = “someone@yourcompany.com”
- SMTP addresses, comma seperated, of who you want the report emailed to
- $SmtpClient.host = “smtp.yourcompany.com”
- The SMTP host name to handle your email report (your Exchagne 2007 Hub Transport server(s) or Exchange 2003/2000 front-end server(s) typically, make sure you can perform anonymous relay internally though….)
Download the script here…
Disable-ADAccountsSingle.zip (2.9 KiB, 1,086 hits)
Quickly Grant Send As Permissions on a Distribution Group
Every now and then I get a request to grant someone “Send As” permissions on an Exchange Server 2007 distribution group. It’s not that difficult, but perhaps just not very evident at first glance. You can go about it quickly from the Exchange Management Shell (or just plain old Power Shell) like this:
Add-ADPermission -Identity “Group Name” -User “UserName” -AccessRights extendedright -ExtendedRights “send as”
You can use the alias or display name for the user and the display name for the group.
Of course, you could always use Active Directory Users and Computers and set the Send As attribute, which you’ll notice is set for the indicated user after using the Power Shell method.
Read all about the Add-ADPermission cmdlet here.
OALGen in CCR clusters
Just a heads up if you’re running Exchange Server 2007 CCR clusters. Moving the cluster resources (using Exchange Management Console or Exchange Management Shell) does not update the OALGen registry settings accordingly. So, if you normally run your CCR clusters active the “A” node, when you move them to the “B” node, OALGen will start throwing errors once per day with an Event ID of 9395 as seen below.
Event Type: Warning
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9395
Date: 7/28/2008
Time: 2:12:30 AM
User: N/A
Computer: xxx
Description:
OALGen is running on a cluster continuous replication (CCR) node which does not have registry value ‘SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\CCRCluserName\EnableOabGenOnThisNode’ or it is not set to this node name. Offline address book generation will not be performed.
I don’t know why the cluster move process doesn’t update the registry accordingly, at least it doesn’t in Exchange Server 2007 SP1 UR1. (I wasn’t able to apply UR2 in June due to other maintenance taking a higher priority and now UR3 is out so I’ll just apply that in August during the maintenance window.)
It’s an easy enough fix though as the error itself indicates. Just navigate the appropriate location in the registry of both nodes in the CCR cluster and make the change. I’ll be creating two registry .REG files and just importing them from now on to make the change even faster (and without error).
If you want to perform detailed logging on the next OAB rebuild, which you will want to trigger manually after updating the registry, simply change the logging level for the “OAL Generator” component to Expert by using the following command at the Exchange Management Shell: Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Expert. You can then manually trigger the OAB update by using this command (assuming that you haven’t renamed the Default OAB): Update-OfflineAddressBook –Identity “Default Offline Address List”. You should see a lot of activity in the Application log on that CCR node with an Event ID 9107 being the last entry for OAL Generator.
Event Type: Information
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9107
Date: 7/28/2008
Time: 7:34:24 AM
User: N/A
Computer: xxx
Description:
Offline address list generation finished.
- Default Offline Address List
Don’t forget to set your OAL Generator logging level back down…it’s typically at Low by default, although can check it by using the Get-EventLogLevel “MSExchangeSA\OAL Generator” command. Use the Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Low command to set logging back down.
Tweaking Boris’ maintenance mode script
If you’ve got an Operations Manager 2007 deployment, then you’re probably familiar with using maintenance mode. One of the things that puzzled me was why the Health Service Watcher wasn’t put into maintenance mode when you use the GUI console. Boris wrote a FANTASTIC script that lets you put a group of servers completely into maintenance quickly using Powershell.
Being one to never leave things alone, and wanting to customize the functionality a little bit, I did just that. The first customization I wanted to make was to target the script at a different group, in this case one that I created in a custom MP just for those specific servers that were to be put into maintenance mode. I’ve hard-coded that custom group into the script, as you can see, but you could easily change that to be an input. The second customization I wanted to make was to allow you to choose the reason for putting the the servers into maintenance mode. I also hard-coded the RMS name into the script, although you can certainly change that to be a prompted item as well. Seeing as how I would be using the script typically late at night, I built in a bit of logic as well so that if you don’t choose to START or END a maintenance mode period, the script will END it for you. The same logic applies to choosing the reason, if no matching reason is found, the script will pick Planned Other for you.
Anyhow, I don’t take any credit for the original concept…that’s all Boris. Thanks Boris! If you want to get my customized version, grab it below. You’ll need to run this from the normal Powershell instance, not the specialized (with snap-ins) Operations Manager instance…that can be changed though if you like.
Set-MaintenanceMode.zip (2.2 KiB, 824 hits)
Setting custom RecipentLimits values in Exchange
A while back we had an issue where an employee had composed a new message in Outlook and selected every recipient listed in the Global Address List…every user, every contact, every distribution group and even a few lingering mail-enabled Public Folders. We have a fairly high global recipient limit in place to allow the sending out of all-hands newsletters, etc. from HR and other groups. This user, while not intending to do anything malicious, caused the receiving Hub Transport server to thrash pretty hard for quite some time due to the extremely large number of recipients she addressed the message to, including nearly a thousand distribution groups. Needless to say, there were an extremely high number of LDAP look ups being performed to expand the recipients of that messages. Additionally, there were thousands of copies of the message discarded since most mailboxes are members of more than a single distribution group. Overall, not a good situation in any way. It was certainly a scenario that we hadn’t planned for or thought about in our design, past or present.
As a result of this scenario, I recommended that we reduce our organizational default recipient limits and configure explicit exceptions for those users who should actually be able to send a message to everyone (and who we trust to not do it “accidentally”). The recommendation was approved and thus became policy. Isn’t that how most laws and policies come about anyhow? As a result of something that sounded so far fetched no one thought to plan for it…
While it’s certainly possible to set the custom, higher, recipient limits manually on each of the “allowed” mailboxes, it’s not administratively economical when the list of people allowed to send is large. Thus a conversation ensued between some members of the Exchange PSS team and myself…and the solution was realized: simply use the membership of a distribution group as a collection, on which the custom recipient limits could be applied. Kudos to Stuart P in PSS for the great suggestion!
So the process goes like this: run the Powershell script against the chosen distribution group (which contains all of the “allowed” senders, those who can send to large numbers of recipients) and then change the default global limit to a much lower number that is unlikely to cause any harm to the Exchange organization but doesn’t limit anyone’s ability to conduct normal business.
The script I wrote is attached. You’ll need to save it as a .PS1 file instead of .TXT and insert your values for the distribution group (**DistGroup**) and RecipientLimits value (**Limit**). You can easily set this script to run as a scheduled task if you wanted or just run it each time you change the membership of the distribution group that contains the mailboxes to have the custom recipient limits set.
Set-RecipientLimits.zip (432 bytes, 865 hits)
-
Translator
