Archive

Posts Tagged ‘Exchange Server 2010’

Script: New-WelcomeEmail.ps1 – Automatically Sending a ‘Welcome’ Email to All New User Accounts

March 25th, 2010 47 comments

PowerShell-logo-128x84Note: I’ve updated this script to address a couple of issues. The first is that if a scheduled task was configured for a time frame other than what was configured in the script itself, this would yield sporadic results. I’ve addressed this by writing a time stamp to the registry when the script runs. This removed the requirement of configuring the time in the script itself, and provides resiliency if the script runs at different times. Run the script once manually to set the configuration. I’ve also added some code that verifies the Exchange PowerShell snapin is loaded before attempting to run. If you’d like a feature added, please let me know in the comments below.

Note #2: If you’re using a server that’s not configured for the normal U.S. style time-date format, such as in the U.K., see Neil Hobson’s post at http://neilhobson.blogspot.com/2010/11/powershell-bug.html for information.

Anything that we can do to cut down on repetitive calls to the Help Desk staff is a good thing. When a new employee starts, there are always questions about ‘what is my email address?’, and ‘how do I get to email from the web?”. For years, admins have come up with sometimes complicated methods to send a new user a canned email that tries to answer these questions. With Exchange 2007 and Exchange Management Shell (PowerShell), we can do this quite easily. In fact, the hardest part is deciding what to include in the email message. Let’s get started..

Let’s read some info from the registry to see when was the last time the script ran. If it hasn’t run before, let’s set some initial info:

$strScriptName =  $MyInvocation.MyCommand.Name
if (!(Get-ItemProperty HKLM:\Software\Innervation\$strScriptName -Name LastRun -EA SilentlyContinue)){
# this is the first time the script has run - let's create the registry key and value for future runs
New-Item -path HKLM:\Software\Innervation -EA SilentlyContinue | Out-Null
New-Item -path HKLM:\Software\Innervation\$strScriptName | Out-Null
New-ItemProperty -path HKLM:\Software\Innervation\$strScriptName -Name "LastRun" -Value (Get-Date) -propertyType String | Out-Null
write-host "Initial configuration completed." -ForegroundColor green
}
# get time stamp from registry so we know when it last ran
$LastRun = Get-Date ((Get-ItemProperty -path HKLM:\Software\Innervation\$strScriptName -Name LastRun).LastRun)
$ElapsedTime = ((Get-Date) - $lastrun).TotalSeconds

Let’s define some variables that we’ll use throughout the process.

$strMsgFrom = "Contoso HelpDesk "
$strMsgTitle = "Welcome to Contoso!"

These set the From and Title for the email that we’ll send, as well as get today’s date, and the name of the script. Next, we create a new object to allow sending SMTP email:

$SMTPClient = New-Object Net.Mail.SmtpClient("localhost")

We can replace “localhost” with the IP address of a remote hub transport server if the script is not running on a hub transport server.

Next, we get a list of mailboxes that we need to send the email to. We’ll use a scheduled task to actually run the task. I run mine every 4 hours, but the code doesn’t care how often it runs. It will use the time stamp established above to email all mailbox created since then. We also want to avoid any mailboxes that are disabled. So our query looks like this:

$MBXArray = @(Get-Mailbox -ResultSize Unlimited | ? {($_.WhenCreated -gt (Get-Date).AddSeconds(-$ElapsedTime)) -and ($_.ExchangeUserAccountControl -ne "AccountDisabled")})

We now have an array, $MBXArray, that contains all of the mailboxes that we’ll email. We now cycle through the array via ForEach, and begin to assemble a personalized email message to each user. $mailbox holds the current account in the loop, so we can pull specific info for each user. Note that the text in $strBody is completely arbitrary – you can include whatever you want. Here’s a sample of one I did for a recent client:

ForEach ($mailbox in $MBXArray ) {
$strMsgTo = $mailbox.PrimarySMTPAddress
$strMsgBody = "Hello, "+$mailbox.DisplayName+", and welcome to the Contoso family! Please keep this email for future use. It contains vital information.
--------------------------------------
Username and password
--------------------------------------
Your network username is '"+$mailbox.SamAccountName+"'. Use your username and password to login to the network. Your password should NEVER be shared with anyone except the I.T. department, and only then when requested. Please do not write it down on anything that can be seen by your coworkers. You will be prompted to change it regularly.
--------------------------------------
Email
--------------------------------------
Your email address is '"+$mailbox.PrimarySMTPAddress+"'.

To access your email, calendar, contacts, and tasks from outside of the building, such as from home, you can do so from any Internet connected computer. Simply open Internet Explorer and go to the Outlook Web Access (OWA) page at https://mail.contoso.com/ and log in using your username and password. Please note the 's' in https.

If you’d like to have access to your email and contacts from your cell phone, you will need a cell phone that has Windows Mobile 5 or later, or an Apple iPhone. Blackberry phones are not supported. Instructions for configuring your device can be found in the Frequently Asked Questions (FAQ) section of the Contoso Intranet at https://intranet.contoso.com/helpdesk/Lists/SupportFaq/AllItems.aspx
--------------------------------------
Contact information
--------------------------------------
Once you’re situated, please go to http://directory/DirectoryUpdate and update your information. Log in using your username and password. It’s important that you update your information anytime something changes, such as title, department, phone number, etc. This information is used in various systems and applications, and is your responsibility to keep up to date.
--------------------------------------
Computer, Email, and Internet policies
--------------------------------------
Contoso, Inc. provides a computer for your work tasks. The use of personally owned computers and related equipment is not permitted on our network. Additional information about use of Contoso computers, email, Internet, etc. can be found in the Employee Handbook located in the HR section of the intranet at https://intranet.contoso.com/hr/
--------------------------------------
Technical assistance
--------------------------------------
Should you need technical assistance, please check the Frequently Asked Questions (FAQ) section of the Contoso Intranet at https://intranet.contoso.com/helpdesk/Lists/SupportFaq/AllItems.aspx. If you cannot find an answer there, submit a Service Request on the Contoso intranet at https://intranet.contoso.com/helpdesk. If you are unable to access the intranet site, only then should you email HelpDesk@contoso.com. It is monitored by the whole IT department, and will ensure your issue is resolved in a timely manner.

Thank you, and, again, welcome to Contoso!
The Information Technology Department"

As you can see, we insert the user’s actual account name, email address, etc since that info is available in the ForEach loop. The message is just plain text, so spacing is preserved. URLs will be clickable links as well. Note: You’ll want to pay close attention to quotes and variables, as having an extra or missing quote can cause an error.

Now we actually send the message:

$SMTPClient.Send($strMsgFrom,$strMsgTo,$strMsgTitle,$strMsgBody)
}
# update registry here with a fresh time stamp
Set-ItemProperty HKLM:\Software\Innervation\$strScriptName -Name "LastRun" -Value (Get-Date) | Out-Null

We’ll run this script on a hub transport server. So take the script, available in the DOWNLOAD section below, and save it in your \scripts folder. You’ll also need an Exchange receive connector that will accept email sent from PowerShell scripts. For that, see Creating a receive connector to use for sending email from PowerShell. Now, schedule a task to run every 4 hours using the info in Running PowerShell scripts via Scheduled Tasks.

Point of interest: In the text I send to the users, you’ll see a link to the Directory Update (http://directory/DirectoryUpdate in the example above). This is for Directory-Update, a VERY lightweight ASP app developed by fellow MVP and author Jim McBee and another developer. It’s completely customizable, and allows users to update selected fields of their AD account to help keep the Global Address List (GAL) current. It is worth the small cost, and really helps you keep the GAL full of correct info. I have another PowerShell script that checks AD account fields, and when it finds empty fields (phone number, title, etc), it sends them an email with a link to the Directory-Update web page. Combine that with Automatically updating the Global Address List with mobile numbers from Exchange ActiveSync and it’s like a self-cleaning oven!

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Donations

I’ve never been one to really solicit donations for my work. My offerings are created because *I* need to solve a problem, and once I do, it makes sense to offer the results of my work to the public. I mean, let’s face it: I can’t be the only one with that particular issue, right? Quite often, to my surprise, I’m asked why I don’t have a “donate” button so people can donate a few bucks. I’ve never really put much thought into it. But those inquiries are coming more often now, so I’m yielding to them. If you’d like to donate, you can send a few bucks via PayPal at https://www.paypal.me/PatRichard. Money collected from that will go to the costs of my website (hosting and domain names), as well as to my home lab.

Download

v1.3 – 02-24-2013 – New-WelcomeEmail.v1.3.zip

Send-NewUserWelcome.zip

ScriptImages.zip – image files used in emails

Changelog

See the changelog for this script for information on versions and what’s included/addressed in each.

Update Rollup 2 (UR2) for Exchange Server 2010 Released

March 4th, 2010 No comments

Microsoft has released the following update rollup for Exchange Server 2010:

  • Update Rollup 2 for Exchange Server 2010 (979611)

If you’re running Exchange Server 2010, you need to apply Update Rollup 2 for Exchange 2010 to address the issues listed below.

Remember, you only need to download the latest update for the version of Exchange that you’re running.

Here is a list of the fixes included in update rollup 2:

  1. 977633 Certain third-party IMAP4 clients cannot connect to Exchange Server 2003 mailboxes through an Exchange Server 2010 CAS server
  2. 979480 Users cannot receive new messages if they access mailboxes that are moved to another Exchange Server 2010 RU1 server by using IMAP4 clients
  3. 979431 The POP3 service crashes when a user connects to a mailbox through the POP3 protocol and the user is migrated from an Exchange Server 2003 server to an Exchange Server 2010 server
  4. 979563 Exchange Server 2010 Push Notifications does not work
  5. 980261 This fix introduces the supports for Exchange Server 2010 page patching when a “-1022” disk I/O error is generated
  6. 980262 Event ID 2156 is logged on a computer that is running Exchange Server 2010
  7. 979566 A 0x85010014 error is generated when linked mailbox users try to synchronize their mailboxes with mobile devices in a CAS-CAS proxying scenario in Exchange Server 2010

Download the rollup here.

Installation Notes:

If you haven’t installed Exchange Server yet, you can use the info at Quicker Exchange installs complete with service packs and rollups to save you some time.

Microsoft Update can’t detect rollups for Exchange 2010 servers that are members of a Database Availability Group (DAG). See the post Installing Exchange 2010 Rollups on DAG Servers for info, and a script, for installing update rollups.

Update Rollups should be applied to Internet facing Client Access Servers before being installed on non-Internet facing Client Access Servers.

If you’re installing the update rollup on Exchange servers that don’t have Internet access, see “Installing Exchange 2007 & 2010 rollups on servers that don’t have Internet access” for some additional steps.

Also, the installer and Add/Remove Programs text is only in English – even when being installed on non-English systems.

Changelog: New-ADPasswordReminder.ps1

February 26th, 2010 11 comments

This is the changelog page for New-ADPasswordReminder.ps1. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v2.9 – 09-13-2013

  1. tweaked the filters for retrieving user accounts
  2. Preview parameter removed since -PreviewUser automatically sets $Preview

v2.8 – 05-03-2013

  1. Tons of updates – unfortunately, I haven’t kept a detailed list
  2. OU option added that allows you to target a specific Organizational Unit (OU)
  3. NoImages option tweaked. Run script with -NoImages to send a text only message. No longer need to specify $true
  4. Changed name of script to New-ADPasswordReminder.ps1 to align with my new naming standard
  5. More code optimization
  6. Better cleanup of message text if some variables like $HelpDeskPhone and $HelpDeskURL are not defined

v2.7 – 12-26-2012

  1. Added NoImages option for those that want less of a visual email. Script still sends an HTML formatted email, but it strips out any images and their related formatting.
  2. Cleaned up some code

v2.6 – 09-07-2012

  1. Changed email server variable to the preference variable $PSEmailServer
  2. changed Send-MailMessage syntax
  3. cleaned up Set-ModuleStatus function
  4. Cleaned up HTML code
  5. fixed issue with missing “)” error in the param list
  6. cleaned up the Remove-ScriptVariables function
  7. Added some Write-Verbose statements for better troubleshooting.
  8. Added a simple check to not include password policy requirements if email is going to FGPP user (until I can resolve detection of the FGPP settings)
  9. $PreviewUser specified will now work even if that user is set to PasswordNeverExpires
  10. Setting $PreviewUser automatically sets $Preview
  11. Removed transcript option
  12. Added variable for formatting the date shown in emails (for my non-U.S. people)
  13. Leaving some of the URL parameters blank will now remove the related text from the email sent to users

v2.4 – 01-14-2012

  1. Fixed bug in detecting domain functional level as pointed out by Michael B. Smith
  2. Changed email server parameter to use $PSEmailServer
  3. Changed Send-MailMessage syntax
  4. Cleaned up Get-ModuleStatus code

v2.2 – 09-29-2011

  1. added some missing ‘alt’ tags for some images in email HTML code
  2. added code to determine global minimum password length & format message accordingly
  3. added code to determine global password complexity requirements & format message accordingly
  4. added $HelpDeskURL variable in param block. That resolves the problem of some links that weren’t clickable (whoops!)
  5. added some parameter validation
  6. added ability to target a single OU, and its children
  7. updated the Send-MailMessage line based on user feedback
  8. updated links to point to new blog. This includes the one in the event log message.

v2.1 – 08/31/2011

  1. added some additional code to the section that installs the RSAT-AD-PowerShell feature
  2. corrected code that wouldn’t send mail until a the user was one day into the reminder window
  3. cleaned up HTML code indentations to make it a little easier to read
  4. variable for image path so that editing the HTML is straightforward
  5. added preview mode to see HTML email
  6. added install mode to automatically create scheduled task
  7. updated and enhanced the comment based help
  8. added code for event log logging

v2.0 – 08/15/2011

  1. added email code
  2. added transcript option
  3. added demo parameter & formatted output
  4. added param block with some default values
  5. moved (Get-AdDomain).DomainMode code to outside of loop to help speed up processing (since it really needs to be called only once)
  6. added check for ActiveDirectory module & Exchange snapins
  7. added alert for same day expiration
  8. auto load or install RSAT-AD-PowerShell feature

v1.0 – 02/26/2010

  1. initial version

Updated: Installing Exchange 2010 Rollups on DAG servers – Now With a Script!

December 29th, 2009 1 comment

Having had to install rollups on a bunch of Exchange 2010 servers recently, I took the info from the original post Installing Exchange 2010 rollups on DAG servers and combined it all into a PowerShell script. I also updated the original article to include steps using Exchange Management Console (EMC). Take a look at the original post for the updated info and script.

Installing Exchange 2007 & 2010 Rollups on Servers That Don’t Have Internet Access

December 16th, 2009 No comments

In today’s security conscious organizations, many internal servers don’t have Internet access. This reduces the attack surface for the servers. However, some tasks require Internet access to some degree, such as Windows Updates. That can be mitigated by WSUS or System Center Configuration Manager. But Exchange rollups also look to the Internet, and not having Internet access can cause the rollup installation to take considerably longer, or even fail.

Exchange rollups use signed code, and IE will check http://crl.microsoft.com/pki/crl/products/CSPCA.crl for certificate revocation to validate the code signing. It’s here we time out if there is no Internet connection to that URL.

We can fix this easily by disabling certification revocation in Internet Explorer. Simply open IE, go to Tools>Internet Options>Advanced>Security. Find the “Check for publisher’s certificate revocation” option and uncheck the box.

Click OK and close everything up. Installing the rollup should go much quicker now, since the server won’t check for cert revocation.

If you’re still having other problems with rollup installation, such as managed services not starting (usually affecting Exchange 2007), you may need to tweak some config files. Microsoft has documented this at http://support.microsoft.com/default.aspx/kb/944752 and http://msexchangeteam.com/archive/2008/07/08/449159.aspx

Script: DAG-InstallRollup.ps1 – Installing Exchange 2010 Rollups on DAG Servers

December 15th, 2009 2 comments

As you’ve probably heard, Microsoft recently released the first rollup package for Exchange 2010. Like the Exchange 2007 versions, installation on typical servers is fairly straightforward. However, when we get to Database Availability Group (DAG) servers, there are a few more steps involved. We’ll take a look at those steps here today.

When using DAGs, the idea is to provide a high availability solution. This can include having activated databases spread among 2 or more servers. This is a fabulous feature that is quite popular. But we have to take this into account when applying updates that will either stop services, or require a reboot. We’ll need to make sure there are no activated databases on the DAG server we’re installing the rollup on. To do this, we perform two steps: stop the server from activating any more databases, and take the activated databases and activate them (make them “live”) elsewhere. This will leave us with a DAG server that has no live mailbox connections, and thus, available for updating.

First, we’ll stop the current server from activating databases using some PowerShell. On the server you’re about to update, open Exchange Management Shell and run this:

Get-MailboxDatabaseCopyStatus -Server (hostname) | Suspend-MailboxDatabaseCopy -ActivationOnly -Confirm:$false

Note the “(hostname)”, which basically just says the local server – no need to put an actual server name there (OK, I’ll admit, I’m lazy). At this point, the server will continue to have databases kept up to date, but won’t activate any if another DAG member goes down. Now we perform a switchover, which takes all databases activated on this server and activates them on another DAG node instead. In this example, we’ll activate them on Ex2 using this:

Move-ActiveMailboxDatabase -Server (hostname) -ActivateOnServer Ex2

However, if this is a case where there are more than two nodes in the DAG, we could let the system automatically determine the best mailbox server to use by not specifying the -ActivateOnServer parameter, such as this:

Move-ActiveMailboxDatabase -Server (hostname)

In either case, enter “Y” at the prompt.

This can also be accomplished via the Exchange Management Console a couple of different ways. We can manually activate the individual databases on other DAG members. To do so, open EMC, and navigate to Organization Configuration>Mailbox. Find the database(s) that need to be activated on another server, right click, and choose Move Active Mailbox Database. Click Browse and pick the server you’d like to activate it on, as shown below, and click Move. When it’s done, click Finish. Do this for each of the databases currently activated on the server you want to update.


(click for larger image)

We can also do a full switchover, activating all databases on a single DAG server, or letting the wizard pick. To do so, in EMC, go to Server Configuration>Mailbox. Right click on the server you’re going to update, and choose Switchover Server. In the resulting box, as shown below, choose “Automatically choose a target server” to have Exchange pick the best server to activate a database on, or “Use the specified server as the target of the switchover” to manually pick a server (and then click browse and pick the server).


(click for larger image)

Click Ok, and the switchover will take place. When it’s finished, there is no confirmation that it’s done. You can look in EMC at Organization Configuration>Mailbox. On the Database Management tab, verify that all databases are mounted on a server other than the one you’re updating.

Once that’s finished, we install the rollup. There really isn’t much need to detail that here – just pick ‘next’ all of the way through. It will take some time to run. Click Finish when it’s done.

Once we’re sure the installation was successful, and all services are started, we enable the server to activate databases again using this:

Get-MailboxDatabaseCopyStatus -Server (hostname) | Resume-MailboxDatabaseCopy

This doesn’t activate databases right away – it just allows the server to do so if the activated copy on another DAG node (or the node itself) goes down.

Follow this same process for the remaining servers in your DAG. Disable activation, switchover, install the rollup, and resume activation.

Once all of the servers are updated, we need to make sure that each database is active on the correct server. Each database has a parameter called ActivationPreference that lists the order of preference that a database is activated on servers that hold a copy. This can be viewed in EMS by using

Get-MailboxDatabase | Select Name, ActivationPreference, Server

The Server field shows which server the database is currently activated on, as seen here:


(click image for larger version)

You could use EMC to manually activate the databases back on the original server, or use the code or script below.

Paul Flaherty posted a couple of one liners that we’ll use here. First, we’ll activate the databases on the correct servers using this:

Get-MailboxDatabase | Sort Name | ForEach {$db=$_.Name; $xNow=$_.Server.Name ;$dbown=$_.ActivationPreference| Where {$_.Value -eq 1};  Write-Host $db "on" $xNow "Should be on" $dbOwn.Key -NoNewLine; If ( $xNow -ne $dbOwn.Key){Write-host " WRONG" -ForegroundColor Red; Move-ActiveMailboxDatabase $db -ActivateOnServer $dbOwn.Key -confirm:$False} Else {Write-Host " OK" -ForegroundColor Green}}

This will essentially look at each database, determine which server has the preference of ‘1’, and make sure the database is activated on that server.
(click image for larger version)

Then, we can verify that they are all activated correctly using another one liner from Paul:

Get-MailboxDatabase | Sort Name | ForEach {$db=$_.Name; $xNow=$_.Server.Name ;$dbown=$_.ActivationPreference| Where {$_.Value -eq 1};  Write-Host $db "on" $xNow "Should be on" $dbOwn.Key -NoNewLine; If ( $xNow -ne $dbOwn.Key){Write-host " WRONG" -ForegroundColor Red; } Else {Write-Host " OK" -ForegroundColor Green}}


(click image for larger version)

At this point, we have the rollup installed on all DAG members, and the databases are activated on the correct server. We can also take a script written by Bhargav Shukla to verify which servers have which rollup(s) installed. This is helpful in an environment with a lot of servers to help validate that they are all at the same patch level.

Update: I’ve created a quick PowerShell script that will perform many of these tasks. I used the commands listed here, as well as some basic error handling. Thanks to the contributions of others listed here, it’s now much easier. Perform steps 1 and 2 before installing the update, and 3,4, and 5 after the update.

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Donations

I’ve never been one to really solicit donations for my work. My offerings are created because *I* need to solve a problem, and once I do, it makes sense to offer the results of my work to the public. I mean, let’s face it: I can’t be the only one with that particular issue, right? Quite often, to my surprise, I’m asked why I don’t have a “donate” button so people can donate a few bucks. I’ve never really put much thought into it. But those inquiries are coming more often now, so I’m yielding to them. If you’d like to donate, you can send a few bucks via PayPal at https://www.paypal.me/PatRichard. Money collected from that will go to the costs of my website (hosting and domain names), as well as to my home lab.

Download

DAG-InstallRollup.zip

Also – if you’re installing the rollup on servers that don’t have Internet access, take a look at Installing Exchange 2007 & 2010 rollups on servers that don’t have Internet access

Set-Exchange2010FilterConfig.ps1 – Cleaner Configuration of the FilterPack for Exchange Server 2010

December 14th, 2009 No comments

One of the prerequisites for installing Exchange 2010 Hub Transport and/or Mailbox roles is the installation of the Microsoft Filter Pack. This registers IFilters so that Office 2007 attachments can be indexed. Once Exchange 2010 is installed, the filters must be registered in Exchange. Microsoft provides a PowerShell script that can be copied/pasted and used to accomplish this. But if you’ve run that script, you notice a bunch of messages about settings already existing. Also, once you’re done, you must restart the Exchange Search service.

I’ve cleaned up the PowerShell script a little to check if the setting already exists, and only attempt those that don’t. This yields a much cleaner console output. Also, the script will prompt, and execute, restating the search service. Once you’ve installed Exchange 2010, simply run the script.

Between this script and the previous script released under Automated prerequisite installation via PowerShell for Exchange Server 2010 on Windows Server 2008 R2, installation of Exchange 2010 is getting much more streamlined.

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Download

Set-Exchange2010FilterConfig.zip

Changelog: Set-Exchange2010FilterConfig.ps1

December 14th, 2009 No comments

This is the changelog page for Set-Exchange2010FilterConfig.ps1. You will find a complete list of released versions, their dates, and the features and issues addressed in each. Please refer to the script’s main page for more information including download links, installation details, and more.

v2.0 – 05-08-2010

  1. better detection of installed filter packs
  2. uses Filter Pack 2
  3. includes PDF iFilter pack
  4. menu

v1.0 – 12-14-2009

  1. initial version

Script: Set-Exchange2010Features.ps1 – Automated prerequisite installation for Exchange Server 2010

December 12th, 2009 18 comments

Update: This version resolves two bugs and adds the Adobe PDF Filter Pack and Windows Update menu options.

A while ago, fellow Exchange MVP Anderson Patricio released a script to help automate some of the tasks required before installing Exchange 2010 on Server 2008 R2. While it’s fairly straightforward to do it manually, automating the tasks can help reduce errors and issues – especially for consultants who may install Exchange 2010 often. Not long after Anderson released his script, Paul Flaherty released a revised version Bhargav Shukla released a revised version that streamlined it a little and added some functionality. Now it’s my turn.

More of an exercise to learn a method in PowerShell than anything else, I took Paul’s version and added functionality to the script. Over time, that has increased exponentially, and has become the most popular script on this site.

While SP1 added the functionality to install the required Windows features, I find this method a little nicer, as some tasks can be performed in a more structure manner. This is handy if you’re building a bunch of servers and want a standardized, error-free installation. Tasks such as disabling IPv6, downloading the latest updates, installing required Windows features, etc. are now just a menu option away.

I’ll likely tweak this some more when I have more time. But I’ve used this to build probably a dozen Exchange 2010 boxes so far, and it’s worked well. I welcome any comments or suggestions.

Installation

Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.

Donations

I’ve never been one to really solicit donations for my work. My offerings are created because *I* need to solve a problem, and once I do, it makes sense to offer the results of my work to the public. I mean, let’s face it: I can’t be the only one with that particular issue, right? Quite often, to my surprise, I’m asked why I don’t have a “donate” button so people can donate a few bucks. I’ve never really put much thought into it. But those inquiries are coming more often now, so I’m yielding to them. If you’d like to donate, you can send a few bucks via PayPal at https://www.paypal.me/PatRichard. Money collected from that will go to the costs of my website (hosting and domain names), as well as to my home lab.

Download

v3.3 Set-Exchange2010Features.v3.3.zip

v3.2 Set-Exchange2010Features.v3.2.zip

v1.0 Set-Exchange2010Prereqs.zip

Changelog

See the changelog for information on features added in each version

Update Rollup 1 (UR1) for Exchange Server 2010 Released

December 9th, 2009 No comments

Microsoft has released the following update rollup for Exchange Server 2010:

  • Update Rollup 1 for Exchange Server 2010 (976576)

If you’re running Exchange Server 2010, you need to apply Update Rollup 1 for Exchange 2010 to address the issues listed below.

Remember, you only need to download the latest update for the version of Exchange that you’re running.

Here is a list of the fixes included in rollup 1:

  1. 977439 Exchange Server 2010 users cannot open certain attachments when they access their mailboxes by using Outlook Web App
  2. 977551 Meeting requests that are sent to a room mailbox are not processed in Exchange Server 2010
  3. 977552 Exchange RPC Client Access service crashes in the Handler.dll that is located on an Exchange 2010 Client Access service server
  4. 977553 Exchange RPC Client Access service crashes in Parser.dll on the Exchange Server 2010 CAS server
  5. 977554 The subject or body of a message that is hosted in an Exchange Server 2010 mailbox is not set as expected
  6. 977555 The message body is inaccessible when the property conversion from PR_BODY_HTML to PR_BODY fails
  7. 977556 The body text of an e-mail message is invisible after you create exceptions for a recurring appointment or for a recurring meeting by using a CDO application together with Exchange Server 2010
  8. 977557 An E_FAIL error occurs when you create an exception to a meeting request by using a CDO application for a Microsoft Exchange Server 2010 mailbox
  9. 977558 A folder name is not changed when you try to move and then rename the folder in an Exchange Server 2010 mailbox by using the CopyFolder method of the IMAPIFolder interface
  10. 977559 The location of a meeting or an appointment is not updated on an Exchange Server 2010 mailbox
  11. 977560 Update fails when you use a CDO application to update a recurrence task on Exchange Server 2010
  12. 977561 VSS backup process stops responding when you try to perform a Volume Shadow Copy Service (VSS) backup for Exchange Server 2010 databases

Download the rollup here. It is also available on Microsoft Update.

UPDATE
NOTE:
 Microsoft Update can’t detect rollups for servers that are members of a Database Availability Group (DAG). Scott Schnoll has written an article at MSExchangeTeam.org about how to install the rollup on DAG members.

Installation Notes:

If you haven’t installed Exchange Server yet, you can use the info at Quicker Exchange installs complete with service packs and rollups to save you some time.

Microsoft Update can’t detect rollups for Exchange 2010 servers that are members of a Database Availability Group (DAG). See the post Installing Exchange 2010 Rollups on DAG Servers for info, and a script, for installing update rollups.

Update Rollups should be applied to Internet facing Client Access Servers before being installed on non-Internet facing Client Access Servers.

If you’re installing the update rollup on Exchange servers that don’t have Internet access, see “Installing Exchange 2007 & 2010 rollups on servers that don’t have Internet access” for some additional steps.