The Recipient Update Service (RUS) is responsible for creating and maintaining E-Mail Addresses in your Exchange Organization. The Recipient Update Service creates an Entry (Recipient Update Service (Enterprise Configuration)) for the entire Exchange Organization for modifying objects in the Configuration Container Partition in Active Directory and one additional RUS for every Exchange enabled Domain in this Forest. The Recipient Update Service runs automatically in the background but you can manually start the RUS process if you click Update Now in the corresponding RUS Policy.
Recipient Policies are used to define the email addresses for your organization and to manage messages with the users mailbox.
The logic of the RUS is fairly simple, but often misunderstood. The details of the decision-making process are documented in article 328738
The basic idea is this:
In the Recipient Policies container, you have a set of recipient policies.
- Each policy has a priority and a filter.
- The policy for each user is the policy with the highest priority (the lower the number, the higher the priority) with a filter that matches the user.
- Once a filter is matched no further policies are applied for a mailbox so for simplicity keep the number of policies small.
There are two types of Recipient Policies. The “E-Mail Addresses” policy is the type used by the “Default Policy” created by exchange. This type of policy controls how proxy email addresses are created for new users. The “Mailbox Manager Settings” policy type can be used to purge off mailbox items based on their age or size.
(more…)
My company was moving from our in house email system to a completely new infrastructure with a new email domain name and a new Active Directory domain. The plan was to have users configure a new Outlook profile to connect to the new system at a particular time on the migration day. Because we have little control over when the users will actually make the transition, I want to make sure any new emaill that arrived at the old mailbox would get forwarded to the new mailbox. This would help cover the straggler users who keep sending email to users who had already migrated.
So this script does exactly that…. it takes a list of distinguished names in an input file, connects to active directory and sets the Active Directory attribute for “targetAddress”. This will essentially forward the mail to the targetAddress SMTP location.
The input file can be easily generated with a CSVDE command:
C:\csvde -f input.csv -d "dc=domain,dc=com" -r "(ObjectCategory=Person)" -l "DN"
Connecting to "(null)"
Logging in as current user using SSPI
Exporting directory to file input.csv
Searching for entries...
Writing out entries
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
................................................................................
...........................................
Export Completed. Post-processing in progress...
763 entries exported
The command has completed successfully
Then you can run this script to read it in and make the changes the the mail enabled active directory objects. (more…)
Cisco’s Overview of DHCP Snooping
DHCP snooping is a DHCP security feature that provides security by filtering untrusted DHCP messages and by building and maintaining a DHCP snooping binding table. An untrusted message is a message that is received from outside the network or firewall and that can cause traffic attacks within your network.
The DHCP snooping binding table contains the MAC address, IP address, lease time, binding type, VLAN number, and interface information that corresponds to the local untrusted interfaces of a switch; it does not contain information regarding hosts interconnected with a trusted interface. An untrusted interface is an interface that is configured to receive messages from outside the network or firewall. A trusted interface is an interface that is configured to receive only messages from within the network.
DHCP snooping acts like a firewall between untrusted hosts and DHCP servers. It also gives you a way to differentiate between untrusted interfaces connected to the end-user and trusted interfaces connected to the DHCP server or another switch.
Well thanks for that extremely clear overview…….. what actually is going on? Lets say you have a switch. You hook a DHCP server up to port #1 and designate this as a “trusted” interface and all of the rest of the ports that will have devices connected to them are setup as “untrusted”. You would set this up using the commands:
*** Enable DHCP Snooping & ARP Inspection ***
ip dhcp snooping vlan 100
no ip dhcp snooping information option
ip dhcp snooping database flash:/dhcpdb.dat
ip dhcp snooping
ip arp inspection vlan 100
*** Untrusted Access Interfaces for DHCP ****
Int Range Fa1/0/2 - 48
description Workstation
switchport access vlan 100
switchport mode access
no mdix auto
Int Range Fa2/0/1 - 48
description Workstation
switchport access vlan 100
switchport mode access
no mdix auto
*** Trusted Access Interface for DHCP ***
Int Fa1/0/1
description DHCP Server
switchport access vlan 100
switchport mode access
no mdix auto
ip dhcp snooping trust
DHCP Client requests are forwarded regardless of the trust state of the port, but DHCP server responses are dropped if the port is untrusted.
So lets say on port #2 the switch sees a DHCP discovery packet float by from a DHCP client. Because it is a broadcast message this gets flooded to all ports on the VLAN. The DHCP server connected to port #1 sees the discovery packet and sends an uninicast DHCPOFFER packet to the client. Because this originated from a “trusted” port the offer is allowed to go through. The client recieves the DHCPOFFER chooses an offer from all that it receives and responds with a DHCPREQUEST back to the DHCP server. The server then responds with a DHCPACK and includes the configuration parameters and committed network address. The switch records the client binding port, vlan, mac address, and ip, etc into its local snooping database.
(more…)
As an Exchange administrator we have probably all had that panic call from an administrative assistant want to recall a message that was inadvertently sent to the wrong group. Every end-user knows that Outlooks “Re-Call” capability stinks. Microsoft’s Exchange Mailbox Merge tool can be used to perform this function (Available as a download from Microsoft Here). You’ve probably used this tool before to extract a single user’s mailbox from the Exchange Recovery Storage group to a PST.
We can use a similar technique to extract and delete all of the messages that match a criteria like “SUBJECT” to a PST and then simply throw away the PST.
Before we begin make sure the account you are using is NOT a Domain Admin and has read access to the mailstore and all of the mailboxes. I like setting this permission on the SERVER level and letting it propagte down to the individual mailboxes. You can’t use a Domain Admin account because Exchange explicitly denies Domain Admins read access at the mailbox level.
Startup exmerge, and choose the “Extract or Import (Two Step Procedure).
This allows us to extract the messages that meet our criteria first before trying to import or restore the messages.
Select "Extract or Import (Two Step Procedure)
So first we perform step 1 to extract the messages. (more…)