Pats giving free exchange for Hernandez jerseys (CBS News)

Sorry, I could not read the content fromt this page.Sorry, I could not read the content fromt this page.

View the original article here

Optimizing Microsoft Exchange for the Enterprise, Part II: Hub Transport Server and Lync-SharePoint Integration

Exchange Server 2010 is one of the most flexible and robust products in managing the messaging infrastructure of the organization. It includes a considerable number of features that help control the way emails are exchanged within the premises of the company. While the default setup provides a functional setup, it is worth looking at other features to get the most of this product. In this two-part white paper, we explore these features and take a look at how they can be implemented on top of a standard installation of Exchange servers in the organization. Part 1 examines, Optimizing the Mailbox Server Role and Optimizing the Client Access Server (CAS). Part 2 looks at Optimizing the Hub Transport Server, Miscellaneous Features, and Lync- SharePoint Integration.

The Hub Transport Server, which is responsible for the mail flow in the organization, features very specific settings
that allow Exchange administrators to define how e-mail is routed, and also applies on-the-fly policies to
that e-mail. This not only allows the sending and receiving of e-mail from the internal world, but also to and
from the Internet.

Transport rules are the mechanism that allows e-mail to be modified while in transit. This can be applied to a
message that is going through the Hub Transport Server role. Transport rules can be applied based on filters and
conditions, and can be used for multiple purposes.

Apply disclaimers to messages
Prevent certain types of viruses by patterns
Filter confidential information and apply Rights Management Services templates
Track and archive messages that are sent or received from specific users
Redirect inbound or outbound messages for inspection
Prevent communication between specific groups or users

A transport rule is configured through the Exchange Management Console (Organization Configuration->
Hub Transport-> New Transport Rule) or Exchange Management Shell, using the following sample cmdlet
and parameters.

New-TransportRule -Name 'Rule1' -Priority '0' -Enabled $true -from 'user1@contoso.com' -SentTo
'user2@contoso.com' -BlindCopyTo 'executives@contoso.com'

In this instance, e-mail is copied to specific users when user1 sends an e-mail to user2. More complex settings
with appropriate rule priorities can also be set up.

Address lists are a collection of mail objects that can be seen through Outlook clients or OWA when an end-user
selects a recipient. Address lists are populated to end devices through address book policies that are essentially
a collection of address lists. This feature makes it possible to apply filters to generate custom address lists, and
then create address book policies to different user groups in the organization.

While it is possible to use the default settings, an organization would probably need to create different policies,
depending on the way the organization is logically segmented. For instance, an acquisition or merger can occur
and, by default, users will see mail objects from both organizations, even if they are legally independent, and
they don't communicate. By creating custom address lists, these lists will be smaller and will contain only mail
objects that end-users are sending mail to.

It is possible to configure these settings through the Exchange Management Console (Organization Configuration->
Mailbox-> Address Lists tab. Once the Address lists are configured, you can create a policy
through the Address Book Policies tab.

SMTP connectors need to be configured when mail flows to other organizations or the Internet. They allow the
e-mail to be received from the outside world as well. Internal e-mail is also routed through SMTP connectors;
however, these are stored in Active Directory (AD) and cannot be seen from the management console.

Receive connectors

By default, Exchange can receive e-mails from authenticated senders only through default and client connectors.
If an organization needs to receive e-mail from the Internet, it must allow anonymous types of connections to
the Exchange servers.

It is beneficial to create multiple receive connectors and then define more granular authentication methods,
depending on who is sending e-mail to Exchange.

For example, since e-mail coming from the Internet comes from unauthenticated servers, you can define a
smart host or relay agent that receives the e-mail directly from the Internet, and then configure authentication
between that relay agent and your Exchange hub servers. All e-mail from the relay would be redirected to your
Exchange servers, allowing for greater security on internal servers, as no unauthenticated connection is accepted
on Hub servers.

Another reason we can create multiple SMTP receive connectors is because internal devices, such as printers
and faxes, access Exchange often. These devices all have different authentication settings; thus, you can be more

flexible with authentication in connectors and IP filtering. This way, you are preventing unauthenticated users
connecting to your SMTP servers and anonymously sending e-mail.

Send connectors

It is necessary to create send connectors manually, and preferable to choose to send to a smart host in a DMZ
(such as an Edge server or any other SMTP server solution) rather than sending e-mail directly on the Internet
from the Hub server (through DNS).

View the original article here

Optimizing Microsoft Exchange in the Enterprise Part I: Optimizing the Mailbox Server Role and the Client Access Server

Exchange Server 2010 is one of the most flexible and robust products in managing the messaging infrastructure of the organization. It includes a considerable number of features that help control the way emails are exchanged within the premises of the company. While the default setup provides a functional setup, it is worth looking at other features to get the most of this product. In this two-part white paper, we explore these features and take a look at how they can be implemented on top of a standard installation of Exchange servers in the organization. Part 1 examines, Optimizing the Mailbox Server Role and Optimizing the Client Access Server (CAS). Part 2 looks at Optimizing the Hub Transport Server, Miscellaneous Features, and Lync- SharePoint Integration.

The mailbox server role is one of the most critical components of Exchange. It is the location where the user's data is stored. It is also a key component in the proper functioning of the following:

Hosting of public folder databases;
E-mail address policies and address lists;
Retention policies and messaging record management;
Offline Address Book generation server role.

While the standard setup creates the default mailbox database and allows storage of e-mails, additional features can be used to ease the administration of different types of objects, turn on archival for user mailboxes or implement high availability and failover clustering in the design.

The default storage location of the mailbox database, as well as the logs, is the system drive. For performance and better recovery, it is recommended to move these components on separate physical drives or locations within a SAN. A minimum RAID level, such as RAID1 or RAID5, will provide fault tolerance for that data.

The databases and logs can be moved within the Exchange Management Console (Organization Configuration-> Database Management-> Right-click on database-> Move database path) or with the following sample cmdlet:

Move-DatabasePath -Identity 'Marketing' -EdbFilePath 'D:\DBs\Marketing.edb' -LogFolderPath 'D:\DBs\ Marketing'

Databases will be dismounted while the move operation is in progress.

Exchange Standard Edition supports five database instances, while the Enterprise Edition supports 100. It is recommended to use smaller databases - fewer users are affected in the case of an outage, backup and restore is quicker, more granularity when it comes to applying quotas, and much more.

Resources mailboxes are practical for managing meetings and booking different types of resources, such as projectors, rooms, whiteboards, and other type of equipment. This feature permits the automatic management of the resources through the Resource Booking Attendant, as well as other numerous options that allow administrators to granularly control how resources can be used and scheduled in meetings.

Prior to using resource mailboxes, in a legacy environment, we would create a generic Active Directory (AD) account that would then be treated as the resource object, or we can create specific calendars in public folders, from where management of these objects would be done. Now, a type of mailbox exists exclusively for that purpose.

With resource mailboxes, a specific type of object is created within the organization, and then used in meeting requests of users though Outlook or Outlook Web App. Instead of using a generic account for managing these types of operations, a resource mailbox allows for the creation of a specific type of user account in AD that is disabled after creation.

Key features of the resource mailboxes include the following:

Specify who can use resource objects and exceptions when it comes to users that can override approval of delegates (resource in-policy and out-of-policy meeting requests)
Ability to specify objects found in a specific conference room that users can see through the description of the resource in their Exchange client (resource custom properties)
Control meeting requests though the Exchange client without having to add the resource mailbox as an additional mailbox in Outlook (resource delegates)
Ability to specify properties of a room or resource, such as duration, conflicts, room capacity, etc. (resource policies)
Change common options of the resource mailbox through the Exchange Control Panel

It is possible to create new mailbox resource objects through the Exchange Management Console or through the Exchange Management Shell using the following examples:

Conference room

New-Mailbox -Room -Name 'Room1' -Alias 'Room1' -UserPrincipalName 'Room1@contoso.com' -First- Name 'Room' -LastName '1'

Projector

New-Mailbox -Equipment -Name 'Projector1' -Alias 'Projector1' -UserPrincipalName 'Projector1@contoso. com' -FirstName 'Projector' -LastName '1'

It is also possible to convert an existing legacy room resource account into a resource mailbox using the following command:

Set-Mailbox "LegacyRoom1" -Type Room

Dynamic distribution groups are useful when membership of users change often in e-mail groups. A static distribution group gets its members assigned manually by the recipient administrators. In contrast, dynamic distribution groups take advantage of AD attributes to automatically assign memberships to users by defining filters and conditions.

For instance, when an employee changes function or department, an administrator changes the corresponding attributes in AD, and the user account's membership to an e-mail group also changes without direct interaction to the group properties.

We can use very specific filters to fulfill different business requirements, such as sending e-mail to all users in a specific location, or to accounts that share some information in common.

View the original article here