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, 663 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
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,318 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,087 hits)
Disabling Active Directory User Accounts, Part 1
For a few years now I’ve been using a custom VBScript to disable AD accounts when employees leave the organization. The script was pieced together from some things I knew how to do and others I was able to find elsewhere. The script performed the following tasks:
- Disabled the specified AD account
- Hid the mailbox from the Global Address List
- Removed the account from all groups it was a member of
- Created a text file log of all groups the account was a member of
- Set the password to be changed at the next login
- Set the disable date in the “Title” field (an unused field in my organization)
- Set the RAS settings to disabled
After our upgrade to Exchange Server 2007 earlier this year I noticed that the script was not functioning fully the way it should have. Specifically, the hiding of the mailbox from the GAL was not occurring. Sure, if you looked at the mailbox of an account that had been disabled using the script in the Exchange Management Console, the check box to hide the mailbox from the GAL was checked, but just the same the mailbox was not really hidden from the GAL.
So to correct this issue, I wrote a new script in Powershell (requires the Exchange Management Shell snapin) script that would perform all of the same actions except setting the RAS attribute to disabled.
Both scripts are attached, and annotated where I remembered where certain portions of the script or ideas came from. The VBScript should be able to be run without any changes unless you want to change what it does. The Powershell (Exchange Management Shell) script should only require one change in the variable $domain as shown here: $domain = LDAP://dc=mydomain,dc=local.
VBScript version:
disable_accounts_single.zip (1.7 KiB, 1,408 hits)
Powershell (Exchange Management Shell) version:
Disable-ADAccounts.zip (1.8 KiB, 1,200 hits)
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
