Returning “Automatic” services only in powershell
There are a lot of cases when you might need to check the services on a server and it is a pity that the get-service powershell cmdlet doesn't return the startup type of a service. That makes it useless for tasks like quickly checking what automatic services are not running on a particular server.
Fortunately WMI calls can solve this issue although it would have been much easier to simply use get-service cmdlet.
Here is a quick example of how to use get-WmiObject to return all services that are set to Automatic startup but are currently not running
Get-WmiObject Win32_Service |
Where-Object { $_.StartMode -eq 'Auto' -and $_.State -ne 'Running' } |
# process them; in this example we just show them:
Format-Table -AutoSize @(
'Name'
'DisplayName'
@{ Expression = 'State'; Width = 9 }
@{ Expression = 'StartMode'; Width = 9 }
'StartName'
)
Creating a DAG in Exchange 2010 SP1 multi-tenant mode
After my posts about Exchange multi-tenant or hosting mode I got a lot of questions about how to create Database Availability Group, or DAG, when running Exchange hosted. So I decided to dedicate a post on how to configure/create DAG using powershell.
Technically the below applies to any exchange setup but, since when running in hosting mode there is no more Exchange Management Console, it might be specially useful if you are trying to configure a DAG while running exchange in multi-tenant mode.
The setup
For this article I am using 2 Exchange 2010 SP1 servers running the mailbox role in multi-tenant mode configured as below
| Name | LAN IP | Replication network IP |
| VSMBX1 | 10.2.1.71 | 192.168.99.71 |
| VSMBX2 | 10.2.1.72 | 192.168.99.72 |
Disable & Enable Organizations in Exchange 2010 SP1 multi-tenant
One thing I have noticed while working with Exchange 2010 SP1 installed in hosting (or multi-tenant) mode is the lack of the possibility to disable/enable a tenant organization.
There is a lot of scenarios when disabling a tenant organization can be very handy and useful. For example if a client didn't pay, you might want to suspend his account without deleting the whole organization and making him lose data.
I have recently developed my own scripts to disable and enable, or suspend and resume, a specific organization for a client of mine and never thought of sharing them until yesterday when this same question popped up on the technet forum and I thought that they might be helpful for some of you so here they are.
Disclaimer
I need to start with a disclaimer, I have built these script for my own use so they are not polished and might be lacking a lot of features and surely have some bugs. Although I am ready to work on them and enhance them if they find interest and feedback I am not to be held responsible for any damage they might cause to your environment. So, in short,
THE SCRIPTS ARE PROVIDED FREE OF CHARGE AND "AS IS" WITHOUT WARRANTY OF ANY KIND, AND MAY NOT BE ERROR FREE. ANTOINE KHATER, THE AUTHOR OF THESE SCRIPTS, DISCLAIM ALL WARRANTIES AND LIABILITY FOR ANY KIND OF DAMAGES AND/OR LOSS.
Autodiscover/Outlook anywhere fails when using a wildcard certificate
A very common issue faced with people who buy a wildcard certificates is that Autodiscover and Outlook Anywhere will not work because the Certificate Principal Name *.domain.com doesn't match the name returned by the autodiscover service server.domain.com
This issue is a pretty easy fix it is enough to run from Exchange Management Shell to match the Certificate Principal Name with the setting returned by the autodiscover service.
Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.domain.com
You can verify the changes you have done by running
Get-OutlookProvidernew-TestCasConnectivityUser.ps1 fails with Verify that OU ( Users ) exists
When trying to run the new-TestCasConnectivityUser.ps1 script the latter might fail with the following error
CreateTestUser : Mailbox could not be created. Verify that OU ( Users ) exists and that password meets complexity requirements.
The first thing you need to do is making sure that the password does meets complexity requirements however if you did and still having the failure you most probably have multiple OUs with name "Users" and that is why the script is failing.
Quick Tip: Restarting all Microsoft Exchange services
There are times when you need to restart all Exchange related services so here are 2 small scripts that will help you achieve this without going over each service in the Services mmc.
Of course restarting the "Microsoft Exchange Active Directory Topology" will restart a most of them but these 2 will restart them all.
Restarting All Running Services
This will get all services starting with MSexchange that are running and restart them.
$services = Get-Service | ? { $_.name -like "MSExchange*" -and $_.Status -eq "Running"} foreach ($service in $services) {Restart-Service $service.name -Force}
Restarting All Running Services with startup type Automatic
Although the above script should be enough in most cases, it will not restart any Microsoft Exchange related service that is supposed be running but is not for any reason. Here is another version of the script that would take care of this issue, note that we are looking for all services starting with MSExchange with startup type Automatic and restarting them
$services = get-wmiobject win32_service | ? {$_.name -like "MSExchange*" -and $_.StartMode -eq "Auto"} foreach ($service in $services) {Restart-Service $service.name -Force}
That's it for now