Does the Active Directory user have an Exchange Mailbox?

Part of a script I built to deal with starters and leavers is to hide a leavers mailbox from the GAL.

I do this because
• We do not re use user objects, we keep them in a disabled state so references to sAMAccountNames in audit logs are valid.

• Leaver’s mailboxes stay online for 3 months after a leave date, as frequently the line manager may require access.

• After 3 months we archive and remove leavers exchange mailboxes, but as above the user object stays.

All leavers accounts are in a generic “leavers OU”

To hide the account from the GAL, the script loops through each user in the leavers OU and if the hidden from GAL attribute on the mailbox isn’t true, it sets it.

Simple enough,  but there will be users in there who no longer have Exchange mailboxes as they have been archived.  So the script errors all over the place because the get-mailbox $user part of the script fails for those objects.
So, I want to wrap an IF statement in the loop to only look for the variable if the user has an exchange mailbox.

How would I know? There are lots of obvious attributes I can think of, but how do I know that they are removed when the mailbox is disabled / gone.

So quite simply, I took a dump of get-aduser $user BEFORE disabling the mailbox, and then after and compared them.

The following attributes have data in them when a mailbox is present, and are null when a mailbox is disabled.

EmailAddress
homeMDB
legacyExchangeDN
mail
mailNickname
mDBUseDefaults
msExchDumpsterQuota
msExchDumpsterWarningQuota
msExchELCMailboxFlags
msExchHomeServerName
msExchMailboxGuid
msExchMailboxSecurityDescriptor
msExchMailboxTemplateLink
msExchMobileAllowedDeviceIDs
msExchMobileMailboxFlags
msExchOWAPolicy
msExchPoliciesIncluded
msExchRBACPolicyLink
msExchRecipientDisplayType
msExchRecipientTypeDetails
msExchTextMessagingState
msExchUserAccountControl
msExchVersion   
proxyAddresses
showInAddressBook
textEncodedORAddress 


I used msExchMailboxGuid in my script

Foreach ($user in $leavers)
{
      If ($user.msExchMailboxGuid)
      {
             $mailbox = Get-mailbox $user.samacountname
             If ($mailbox. HiddenFromAddressListsEnabled -eq $False)
             {
                    Try
                    {
                              Set-Mailbox -Identity $User.SamAccountName -HiddenFromAddressListsEnabled $True
                    }
                    Catch
                    {
                             $_.exception.message
                    }
            }
      }
}

Changing IP Settings on an SQL Cluster

This simple five minute job during an implementation  really threw me.

To paint a picture there is a three node SQL cluster with two instances (2 Active nodes, one Passive) these are isolated from clients behind a firewall.

To facilitate a hardened firewall policy to permit only TCP 1433 to the instance resource group IP addresses, as well as  ensuring only the instance resource group IP address listens on that port (opposed to the default ALL IP’s setting) some changes are required to the network settings in SQL configuration manager.

On a standalone SQL server, it’s simply a matter of changing the settings using the Configuration Manager GUI, restarting the SQL service and the change takes effect. However when in a cluster the changes revert back to the previous ones immediately after clicking ok.

After venturing into this issue a bit more I discovered what I was trying to do wasn’t really documented any ware, but some other articles pointed me in the general direction of the joys of quorum in clustering. In a nutshell I was making a change on one box but as the registry settings being changed are managed by the cluster service the the other two nodes in the cluster won quorum and overwrote the settings.

To change these settings the cluster the reservation checkpoint for the registry path needs to be removed, the changes made in the registry and then the cluster reservation checkpoint added again.

The first step is to get the checkpoint name of the instance you are going to modify, run the following command:

Cluster res /checkpoints

Once you have the instance name, take the SQL server offline in failover cluster manager and run the following command:

cluster res "SQL Server (INSTANCENAME)" /removecheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.INSTANCENAME\MSSQLSERVER"

You should now edit the registry or use SQL configuration manager to make the changes you wish to make.
Personally I prefer to edit the registry as this enables you to delete the unused IP addresses and just leave the cluster IP in place, which is much tidyer.
The path to edit the registry settings is

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.INSTANCENAME\MSSQLServer\SuperSocketNetLib\Tcp\

Delete any of the IPx keys you don’t need but leave IPAll
To specify the port for the IP address to listen on, simply modify the TCPPort value, and remove the value from the TcpDynamicPorts
Once you are happy with the changes, run the following command to add the checkpoit back into clustering

cluster res "SQL Server (INSTANCENAME)" /addcheck: "Software\Microsoft\Microsoft SQL Server\MSSQL.INSTANCENAME\MSSQLSERVER"

Bring the SQL Server resource back online and check SQL configuration manager, the changes should have taken affect.

As a result of this change, your firewall rules will be more secure as the massive dynamic port range doesn’t need to be permitted and if need be both SQL instances can be failed over to the one server without ports comflicting. There is also the added bonus that the IP configuration in SQL configuration manager looks a whole lot tidyer.

Getting service tag / bios info using powershell

Following on from my post “script to get service tag from dell device” I felt a bit “dirty” that I was using VB opposed to my new favourite thing in the world, powershell!

You can use a cmdlet “get-wmiobject” to pull all sorts of info from WMI, including the bios.

Therefore, this very simple one liner will return not only the service tag (or serial number for non dell devices), but bois version and a raft of other information.
Here is the command

Get-wmiobject win32_bios | fl *

The result will look something like this

If you have WinRM remoting configured, you can run this on a remote device by starting an interactive session, and then running the command

PS> enter-pssession servername
Server name: PS > get-wmiobject win32_bios | fl*

If you don’t have WinRM remoting enabled, run this command on the host to enable it.

PS > winrm quickconfig
WinRM already is set up to receive requests on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Enable the WinRM firewall exception.

Make these changes [y/n]? y

WinRM has been updated for remote management.

Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.

Configuring default FTP logon domain

If you’re still stuck in the dark insecure age of the internet and using FTP, you may want users to login to your FTP site using their domain credentials.

By default, the FTP service will use the local user database on the server itself (unless you enter your username in the domain\username format), you can however configure IIS to use a domain by default.

Take caution in doing this though, if you’ve ever put an FTP server on the internet, take a look at the event logs, it will have a ton of brute force attacks on it within minutes.
By default FTP will be trying to authenticate locally, which is a much smaller attack surface (fewer users) as soon as you point it at your domain, it’s going to have a much larger attack surface (more users)

You need to make sure you don’t have any accounts such as “test” or users like “mary” with passwords of “password” or any dictionary word at all. You should also tie the FTP site down to the specific users that need access, so if an account does get compromised it can’t be used to put data in the FTP directory.
With the above in mind, use an elevated command prompt to run the following on the FTP server

adsutil set msftpsvc/DefaultLogonDomain "YourDomainName"

This will set the default logon domain for all FTP sites.

Viewing queues on all hub transport servers in one handy PowerShell command

I can’t take any credit for this, a college and I came up with the idea that we needed a way of viewing the queues on all of our hub transport servers in once place, opposed to having to connect to each one individually, it just so happened that he came up with the goods quicker than I did!

So what is the problem?  Using the queue viewer in EMC, it will only display the queues on the server you have selected, the same goes for the PowerShell command get-queue; you have to specify a hub transport server.

The solution, pipe the results of a get-exchangeserver cmdlet filtered to return hub transport servers into the get-queue command.
Here it is – enjoy!

get-exchangeserver | where {$_.ishubtransportserver -eq $true } | get-queue | sort messagecount –descending

Thanks Jon!

Creating a dynamic distribution group based on any Active Directory attribute in exchange 2010

A Common requirement I’m sure for most businesses is to be able to send a mail to all users who are located in a specific building.

A dynamic distribution group based on the office attribute is surely the answer – well yes it is, but not using the Exchange Management Console.

I have the office attribute set for each user within active directory

However, if you use the exchange management console to build your query, its options are limited and does not include the office attribute.

Although using the EMC it isn’t possible, it can be done in powershell.

The new-dynamicdistributiongroup cmdlet doesn’t natively support anything other than the attributes you see listed in the EMC, however you can use a recipientfilter to specify any attribute you like.

The command below will create a dynamic distribution group called “Users in Example Office name” which will contain any user with the office location set to “Example office Name”

New-DynamicDistributionGroup -Name "Users in Example Office Name" -OrganizationalUnit "domain.net\users" -RecipientFilter { ((RecipientType -eq 'UserMailbox') –and (Office -eq 'Users in example office name')) }

This command can be extended futher using the –and variable. The command below would create the same dynamic distribution group, only the members would be those who are in the “Example office name” building AND their manager is James Bond

New-DynamicDistributionGroup -Name "Users in Example Office Name" -OrganizationalUnit "domain.net\users" -RecipientFilter { ((RecipientType -eq 'UserMailbox') -and (Manager –eq 'James Bond') –and (Office -eq 'Users in example office name')) }

A quick way to set calendar permissions using Powershell

A Common request from users is to grant others access to their calendars.
You can either talk the user through this, or setup a new outlook profile to open their mailbox and set it yourself using the GUI – both are time consuming.
This simple powershell command allows you to set permissions with ease:

add-mailboxfolderpermission -identity USERNAME:\calendar -user "Username of person who needs access" -accessrights reviewer

The Identity switch needs to be the username of the mailbox which you are giving access TO, the user switch is the user you are giving access FROM.
The accessrights switch is the level of access you wish to grant the user, the link below lists some additional switches you can use:

http://technet.microsoft.com/en-us/library/dd298062.aspx

Using Powershell to grant access to all user mailboxes, or a whole exchange database

You may have a requirement to be able to open any users mailbox in your exchange 2010 environment.

The first thing to consider, is how you will control access, will you add individual users, or a security group with users in it.
A security group is the most efficient and tidiest by far, therefore this post will assume you are using a security group.

Method one

The first option is to give the security group full access to all user mailboxes

Advantage

The permissions will follow the mailbox around when it is moved between databases

Disadvantage

You will have to apply the permission to all new users you create

To use this method, use the Exchange Management Shell (also known as Powershell or EMS)to get all the mailboxes in your organisation, and then pipe this into a command that set the permissions:

Add-PSSnapin Microsoft.Exchange.Management.Powershell.Admin -erroraction silentlyContinue

$userAccounts = get-mailbox -resultsize unlimited

ForEach ($user in $userAccounts)

{

add-MailboxPermission -identity $user -user “Your Security Group Name” -AccessRights FullAccess

}

Method two:
The second option is to apply the permissions to the exchange mailbox database, so all mailboxes within that database will inherit those permissions.
Advantage

All new users will automaticly inherit the permissions you set on the storage group

Disadvantage

If different permissions are set on different databases, when users are moved between databases they will not be subject to the permissions that were assigned to the original database.

Use EMS to run the following command

Add-ADPermission -identity YourDatabasename -user “Your Security Group Name” -AccessRights genericall

Draining sessions from Remote Desktop Session Hosts / Terminal Servers

Maintaining terminal servers (or remote desktop session hosts as they are known now) in today’s world when users require access 24/7 is a challenge. Setting up an RDS farm, with a session broker will give you load balancing and fault tolerance. (I will write more about remote desktop server farms and session brokers in another article)

However notice I say “Fault Tolerance” this doesn’t mean that you can reboot session hosts without affecting users, it just means that your system will tolerate the failure of a session host. The users who were connected to the rebooted (or failed) session host will lose what they were working on and will have to reconnect.

The nature of a session broker is that it will try to distribute sessions evenly across all members of a farm; this is great, apart from when you want to reboot a session host without annoying your users.

There is no “live migration” of RDS sessions, once a user is on a host, that’s where they will stay until they log off. 

So how do you free up a session host to perform maintenance on it? Firstly you will need to plan your work in advance.

You can then use the “chglogon” command to begin “draining” sessions. There are many ways sessions can be drained, but it basically means the session host will stop accepting new connections. Eventually once your users have logged off, they will not be able to establish a new log onto the draining session host, so will establish a new connection on another session host, which mean eventually the session host you are draining will have no users logged into it.

There are four switches for the chglogon command:

/query – this will tell you what mode the session host is currently in

/enable – allows users to establish connections to the session host

/disable – doesn’t allow any new connections, or reconnections to an existing session.

/drain – doesn’t allow any new connections, but does allow users to reconnect to an existing session

/drainuntilrestart – does the same as /drain, but reverts to /enable after a reboot

NOTE: when using the /disable switch, this will prevent you reconnecting to the server via RDP. You need to ensure you have access to the console via another method other than RDP, or use the RD configuration utility from another RDS server to change the setting.

These commands could be utilised to help with automated updates. You could configure RDS1 to automatically install updates on a Saturday at 6PM, then create a scheduled task to run on a Friday at 6AM to run the chglogon /drainuntilrestart command.

This would hopefully mean by Saturday at 6PM there were no users left on RDS1 and it would be safe to automatically reboot after an update installation.

You could then use the same method with RDS2, RDS3 etc, but on different days to ensure 100% uptime of your RDS farm

Using servermanagercmd to automate the installation of common roles and features in Windows Server 2008 (inc R2)

I try to configure as many of the settings on a server via group policy. This not only saves time, but provides 100% consistency and a very simple way of making system wide changes. An example of this is I will configure SNMP settings via group policy.



This is all well and good, but many of the configuration settings are dependent on a “role” or “feature” that may not be installed (such as SNMP) there is no built in way to automatically install roles and features using group policy like there is to configure services, or firewall rules.


This is where servermanagercmd comes in. as you will probably gather this is a command line interface to the server manager GUI.


If you’re deploying a large amount of servers and you want to avoid manually installing a common role or feature, this is very useful, and will save hundreds of clicks!


Within the Active Directory design of the network I support, each server role has its own OU, which is under a generic servers OU. In most cases there is a group policy applied to each OU, so settings specific to a server role can be set.


Because of this, I can use group policy preferences to create a registry entry under the runonce key which will run servermanagercmd with the appropriate switches to install what I want based on the role of the server.


The runonce key is located:

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

Any REG_SZ string that is created under this key will be run once on startup (hense the name)


I typically install three features on most of the servers I look after, Telnet Client, SNMP Services and Failover clustering, these are the commands I use:

Servermanagercmd –install –telnet-client

Servermanagercmd –install snmp-services –allsubfeatures

Servermanagercmd –install failover-clustering

You will notice on the SNMP string, I have added –allsubfeatures, this installs all the sub features under the feature or role heading you have specified.


More information on the servermanagercmd as well as switches for other roles and features can be found here:


http://technet.microsoft.com/en-us/library/cc748918(WS.10).aspx


Other switches of servermanagercmd worth noting are:


-query this will output the current roles and features installed


-remove this does the opposite of add