jump to navigation

Unified Communications by Yann Espanet | MS Office Communications,Lync,Exchange,VoIP,telephony March 14, 2011

Posted by John Ruby in Overview, Troubleshooting & Knowledge Bases.
add a comment

 

Enabling Any SIP Phone & Any SIP Trunking Service Provider with OCS 2007 R2 !

Goals of the demo :

Use asterisk like a UPD/TCP translator between OCS and a SIP trunking services in UDP mode.

  • make calls from Microsoft Office Communicator to the sip trunk
  • dial froma external mobile or a PSTN phonetrough the sip trunk and answer the call on eithera hard or soft phone or Office Communicator.
  • control forwarding and simultaneous ringing options from the Communicator

I use Asterisk 1.6 which support TCP and UDP installed on CentOS 5 – Kernel 2.6.18

Installation steps :

  1. Add a mediation server to the OCS infrastructure
  2. Add an asterisk server
  3. Configure Mediation server to use the asterisk box
  4. Resolve NAT problem (if needed)
  5. Create two SIP trunks :
    1. Asterisk to OCS
    2. Asterisk to SIP Trunk service
  6. Define the context used by this trunks
  7. Configure follow me
  8. Test the infrastructure

 

Basic schema :

OCS R2 —- Mediation —- Asterisk —— Firewall — SIPTrunk
MTLS —- TCP —- UDP —- NAT —– UDP

I use Hyper-V for the two OCS servers and VMware for the Asterisk server.

Step-by-steps

Step 1 : Add a mediation server to your infrastructure
  1. Install a mediation server
  2. Configure certificate
  3. Add the OCS reskit tools (useful for troubleshooting)
  4. Create a dial plan
  5. Create a location profile with two normalization rules.

The first will be use for internal numbering and the second is a generic rule that redirect all call that do not correspond to a valid extension number in OCS to the default gateway.

Internal : OCS user have an three digit extension beginning by 2

Phone pattern : ^2(\d{2})$

Translation pattern : +2$1

Generic rule : All number are concerned (be careful to put this rule in second position in your location profile)

Phone pattern : ^(.*)$

Translation pattern : $1

Assign your location profile to front-end server (properties of the pool / properties of front-end / Voice Tab)

NB : Test your dial plan using the Enterprise Voice route helper

The first will be use for internal numbering and the second is a generic rule that redirect all call that do not correspond to a valid extension number in OCS to the default gateway.

  • Internal : OCS user have an three digit extension beginning by 2

Phone pattern : ^2(\d{2})$

Translation pattern : +2$1

  • Generic rule : All number are concerned (be careful to put this rule in second position in your location profile)

Phone pattern : ^(.*)$

Translation pattern : $1

Assign the location profile to the front-end server (properties of the pool / properties of front-end / Voice Tab)
NB : Test your dial plan using the Enterprise Voice route helper

Step 2 : Add an asterisk server
  1. Download trixbox 2.2 Virtual Appliance from VMware website http://www.vmware.com/appliances/directory/939
  2. Configure basic settings (Ip address, ..)
  3. Add this line in the begining of sip.conf

tcpenable = yes
bindport = 5060

  1. Access the web Trixbox interface (use Mozilla) In system menu / Network / Configure IP, Subnet, DNS and a valid hostname on internet : Ex : sip.mydomain.com
Step 3 : Configure Mediation server to use the asterisk box
  1. Open the properties of your mediation server verify that :
  2. in General tab : the gateway listening port is 5060
  3. In next hop connections tab : put the IP address of your asterisk server in PSTN gateway next hop with 5060 for the port number
Step 4 : Resolve NAT problems (if needed)
  1. In Asterisk, Go to PBX / Config File Editor / and edit SIP_NAT.conf

nat=yes

externip=Valid_FQDN

localnet=Your_Localnet/Your_Subnet

  1. Open in your firewall port
    • 5060 in UDP and TCP for SIP
    • RTP: 10000 to 20000 UDP
  2. Verify that you can see you valid public IP in the Trixbox system status
Step 5 : Create two SIP trunk in Trixbox : asterisk to OCS and Asterisk to SIP Trunk service
  • Asterisk to OCS

Trunk Name : ocs

PEER Details :

host=ip-mediation-server

type=peer

qualify=yes

transport=tcp

insecure=very

port=5060

canreinvite=yes

fromdomain=yourdomain

context=from-ocs

Incoming Settings :

User context : (I put a OCS username here)

User details :

host=ip-mediation-server

type=peer

transport=tcp

insecure=very

port=5060

context=from-ocs

register string :

(leave blank)

 

  • Asterisk to SIP Trunk service

Trunk Name : siptrunk

PEER Details :

type=friend

disallow=all

allow=ilbc&speex&gsm&alaw&ulaw

username=username

secret=password

host=yoursipregistrar

canreinvite=no

context=from-siptrunk

Incoming Settings :

Clear all

register string :

username:password@yoursipregistrar (/yournumber if needded)

 

Step 6 : configure context

Edit Extension_Custom.conf and add a the end of the file :

[from-ocs]

exten => _X.,1,Answer

exten => _X.,2,Dial(SIP/${EXTEN}@siptrunk,,tr)

#include extensions-away-status.conf

[from-siptrunk]

exten => _X.,1,Set(numDialled=+${EXTEN:Number_of_X_to_ignore})

exten => _X.,2,Set(__FROM_DID=${EXTEN})

exten => _X.,3,Answer

exten => _X.,4,Dial(SIP/${numDialled}@ocs,,tr)

exten => _X.,4,Dial(SIP/${numDialled}@ocs)

Step 7 : Configure follow-me in Asterisk

Assign line number from your sip trunk to Asterisk extension and redirect to phone extension in OCS by using a # after the number.
DID number from your SIP trunk provider —> Extension in Asterisk —> Follow-me to OCS extention (use # after the number to precise that it’s external to asterisk)

Step 8 : Test the infrastructure
  1. Troubleshooting tools that you can use in Asterisk :
    1. Log as root with a terminal tools (putty) / Type asterisk –r / Type sip set debug on
    2. Assign a line prefix to test the trunk from a softphone directly connected to Asterisk
      Ex : Create a outbound route with “9|.” to test the trunk by dialing 9 before the number
  2. Troubleshooting tools that you can use in OCS :
    1. Eventviewer
    2. Use the Debug tools (right click your mediation server)
    3. MS Netmon
    4. OCS Route helper to validate your dial plan.

Have fun with that and leave me a message if encounter some problems!

It’s probably possible to do the same withother IP/PBX like : Freeswitch, OpenSer, SipxECS, …

Date : 04/08:2009 – Author : Yann Espanet – mail : yann@unifiedcommunications.eu

Unified Communications by Yann Espanet | MS Office Communications,Lync,Exchange,VoIP,telephony

Enable virtual network optimization in SCVMM – VirManSec Community March 13, 2011

Posted by John Ruby in Solutions, Troubleshooting & Knowledge Bases.
add a comment

 

This checkbox is used to enable and disable VMQ. Select the check box to enable VMQ for those virtual machines with the heaviest network load and clear the check box to disable VMQ for other virtual machines.

The following links provide some additional insight into this check box and VMQ that I hope you will find useful.

Configuring Virtual Networks in VMM

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

How to Configure Network Adapters for a Virtual Machine

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

Networking Deployment Guide: Deploying High-Speed Networking Features

http://download.microsoft.com/download/8/E/D/8EDE21BC-0E3B-4E14-AAEA-9E2B03917A09/HSN_Deployment_Guide.doc

enable virtual network optimization in SCVMM – VirManSec Community

Forget Intel’s Thunderbolt, Wireless USB is the game-changer | ZDNet March 13, 2011

Posted by John Ruby in Technologies.
add a comment

 

Last week Intel made a big deal about the official launch of its Light Peak technology — now called Thunderbolt — which enables much faster data transfers (10Gbps) and the ability to consolidate accessories and video connections into one cable with a connector that is half the size of a USB plug.

While those are useful features, the arrival of Thunderbolt had me scratching my head and asking two big questions:

  1. What happened to USB 3.0?
  2. Where’s Wireless USB?

Both of those technologies have been in development for years, but somehow Light Peak/Thunderbolt was able to leapfrog them, at least in terms of getting the green light from Intel and its partners.

Some of that certainly has to do with Apple getting on board with Thunderbolt. Apple’s new line of MacBook Pro laptops are the first computers to include Thunderbolt. Also, while Thunderbolt was originally expected to use the same type of connector as USB (a confict with USB-IF apparently prevented that), when Thunderbolt was unveiled last week it was surprisingly announced that it will use a Mini DisplayPort connector — a technology developed by Apple and licensed without a fee.

One of the big advantages of Thunderbolt is that it’s capable enough to handle LCD monitors and other displays so it can replace the need for VGA, DVI, or HDMI ports on laptops and desktops. That means users only need to worry about one type of cable for all of their accessories. However, USB 3.0 (also called “SuperSpeed USB”) has been developing the same thing. A number of display manufacturers have mentioned to me in recent years that USB 3.0 will eliminate the need for those other video connectors in computers and allow users to connect their monitors to a USB port. Will display makers dump the work they’ve been doing preparing for USB 3.0 and switch to Thunderbolt? I doubt it, at least not right away.

Also, keep in mind that USB 3.0 is backward compatible with the millions of existing USB peripherals as well, while Thunderbolt will require adapters to work with them. The only drawbacks to USB 3.0 versus Thunderbolt are 1.) it’s half as fast (5Gbps for USB 3.0 vs. 10Gbps for Thunderbolt) and 2.) the USB 3.0 connector is a little larger.

However, the real missed opportunity here is Wireless USB. That’s the technology that I would love to see Intel pushing instead of Thunderbolt. Sure, Thunderbolt will deliver faster file transfers and consolidate cables, but Wireless USB is a much bigger game-changer. It can reduce accessory cables altogether and has the potential to introduce a universal wireless docking solution that could turn the computing industry on its head. In fact, the latter is probably why Intel isn’t pushing it — that type of radical change isn’t in their self-interest. More on that in a moment.

First, let’s talk about the elimination of accessory cables. This is long overdue. At the same time Wi-Fi first came on the scene a decade ago and launched the concept of the WLAN (that’s wireless local area network), there was another hot new term at the time called PAN (personal area network). The idea was that not only would computers connect wirelessly to corporate networks and the Internet, but that there would also be mini wireless networks centered a desktop or laptop machine itself, in order to connect mice, keyboards, monitors, printers, scanners, headphones, PDAs (now smartphones), etc. The hope back then was that Bluetooth would be the enabler of the PAN, but that hasn’t happened because Bluetooth is flaky, slow, and difficult to set up. To make the PAN happen, we need something more robust like Wireless USB.

Building on that concept of the PAN is the idea of the wireless docking solution — this is the killer feature of Wireless USB. Accessory makers have been chomping at the bit for a couple years to get this because it would make it infinitely easier for mobile users to dock a laptop to a full monitor, keyboard, and mouse (using a Wireless USB connection a laptop could simply connect to a dock that has legacy peripherals plugged in).

In fact, it would not only be easy, it would turn Wireless USB into a universal docking solution instead of the current situation where each laptop maker has its own proprietary docking connectors and then badly overcharges for the docks. A universal wireless docking solution would have two big effects for mobile users — it would make docks a lot cheaper and it would likely spawn a lot more places to dock. For example, offices and other institutions could set up public work areas where people could dock to work no matter what platform they are running (Windows, Mac, Linux, iPad, etc), as long as it has Wireless USB. I can even imagine Internet cafes offering docking areas.

However, once we take this idea one step further, then we start to see why Intel may not be so enthusiastic about it. Think about the Motorola Atrix. This is a dual core Android smartphone with 1GB of RAM and Motorola’s “Webtop” software, which allows it to look and act like a full PC when loaded into the desktop dock (with monitor, keyboard, and mouse) and the laptop dock.

Now imagine if the Atrix and other dual core smartphones could perform the same feat, but without having to dock at all by simply using Wireless USB — which offers plenty to speed to accomplish this with 480Mbps at 3 meters and 110Mbps at 10 meters. Suddenly, a lot of smartphones would become potential PC replacements. Same goes for tablets. They could wirelessly dock and become full desktop computers when people needed to do more serious work. Since virtually all smartphones and tablets are powered by mobile ARM chips rather than Intel chips (and Intel has repeatedly been unable to break into the mobile market), this scenario could be apocalyptic for Intel because it would enable people to replace (Intel-powered) laptops and desktops with (ARM-powered) smartphones and tablets.

However, this scenario would be fantastic for consumers and business professionals. But, without Intel to push Wireless USB, who will step up and lead the charge? I’m looking at you, NVIDIA, Qualcomm, Motorola, and Samsung.

Forget Intel’s Thunderbolt, Wireless USB is the game-changer | ZDNet

Customize the Outlook Web App Sign-In and Sign-Out Pages: Exchange 2010 SP1 Help March 12, 2011

Posted by John Ruby in Solutions, Troubleshooting & Knowledge Bases.
1 comment so far

 

Customize the Outlook Web App Sign-In and Sign-Out Pages

Applies to: Exchange Server 2010 SP1

Topic Last Modified: 2010-10-25

This topic explains how to create custom sign-in and sign-out pages for Outlook Web App.

Looking for other advanced management tasks for Outlook Web App? Check out Managing Outlook Web App Advanced Features.

  Customize the sign-in and sign-out pages

The Outlook Web App sign-in, language selection, and sign-out pages are created based on graphics and the logon.css file in the base theme folder. Therefore, to use custom sign-in and sign-out pages, you must modify the files in the base theme folder. You can find the base theme folder in the Exchange installation directory at \V14\Client Access\OWA\<version number>\themes\base.

Ee633483.note(en-us,EXCHG.141).gifNote:

In Exchange Server 2010 SP1, the path is \V14\Client Access\OWA\<version number>\themes\resources.

The sign-in, language selection, and sign-out pages use the logon.css file to define text styles and colors. The pages are created by combining several images for the border top, bottom, and sides and also include repeating images and corners for expansion. The following files create the sign-in page:

  • logon.css
  • lgnbotl.gif
  • lgnbotm.gif
  • lgnbotr.gif
  • lgnexlogo.gif
  • lgnleft.gif
  • lgnright.gif
  • lgntopl.gif
  • lgntopm.gif
  • lgntopr.gif

It is easiest to create a new look by using a solid color because the same collection of images is used for three pages: the sign-in page, the language selection page that is shown on the first sign-in per mailbox, and the sign-out page. The pages resize horizontally and vertically based on the contents of the page.

If you have multiple Client Access servers and want them all to use the same sign-in and sign-out pages, you must copy the modified sign-in and sign-out files to each Client Access server. You should also create a back-up copy of your customized files. If you reinstall or upgrade Exchange, all files in the themes folders will be overwritten. You’ll have to copy your customized files back to the appropriate theme folder after the reinstallation or upgrade is complete.

Ee633483.Caution(en-us,EXCHG.141).gifCaution:

Before you change the files to create custom sign-in and sign-out pages, back up copies of all the files that you’ll be changing before you start to create your custom sign-in and sign-out pages.

The following figures illustrate the default Outlook Web App sign-in page as it appears if the user clicks show explanation and selects This is a private computer and Use the light version of Outlook Web App. One figure shows how the graphics files that create the page fit together. The other figure shows how the logon.css file determines the colors of the background and text on the sign-in page.

Outlook Web Access sign-in page displaying custom graphics files
Outlook Web App default sign in page

Default Outlook Web Access sign-in page displaying text options
Outlook Web App sign in page text options

The following figures illustrate the default Outlook Web App sign-out page. One figure shows how the graphic files that create the page fit together. The other shows how the logon.css file determines the colors of the background and text on the sign-out page.

Outlook Web Access sign-out page displaying custom graphics files
Outlook Web App default sign out page

Default Outlook Web Access sign-out page displaying text options
Outlook Web App sign out page with text options

  Test changes to the sign-in and sign-out pages

After you’ve opened the Outlook Web App sign-in or sign-out page in Microsoft Internet Explorer, you can test your changes without having to reset IIS or exit Internet Explorer.

  1. Open the Outlook Web App sign-in or sign-out page in Internet Explorer.
  2. On the toolbar, click Tools, and then click Internet Options.
  3. On the General tab, under Browsing history, click Delete.
  4. Under Temporary Internet Files, click Delete files, and then click Yes when you are asked whether you are sure that you want to delete all temporary Internet Explorer files
  5. Click OK to close Internet Options.
  6. Click Refresh to see your changes.

Repeat these steps to see your changes every time that you make a change to the sign-in or sign-out page files. If you’re making several changes, you can leave the sign-in or sign-out page open and repeat the steps to see your changes.

  Change the logo in Outlook Web App

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Graphics editor" entry in the Client Access Permissions topic.

To customize Outlook Web App, you can change the Outlook Web App logo on the sign-in and sign-out pages to your organization’s logo.

  1. Create copies of the files that you want to change, and then save them to a safe location so that you can restore the original pages, if it’s necessary.
  2. Open the lgntopl.gif file by using an image editing tool, and then modify it to create the logo that you want to use.
  3. Save your changes, and then click the Refresh button to see your changes.

Ee633483.note(en-us,EXCHG.141).gifNote:

If you’ve changed the background color of lgntopl.gif, we recommend that you modify the remaining files that are used to create the sign-in and sign-out pages to match.

  Change the font styles and colors

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Text editor" entry in the Client Access Permissions topic.

You can edit the logon.css file to change font styles and some of the colors that are used on the pages. This includes the background color that’s behind the controls in the center of the sign-in page and the language selection page. If you’ve changed the color of these pages, we recommend that you change the background color to match.

To change the background and font colors of the sign-in, language selection, and sign-out pages, you must find the values in the sign-in style sheet (logon.css) and then determine the HTML RGB values for the colors that you want to use. The HTML RGB color values are defined by a seven-character string in the format of the number sign (#) followed by a string of six characters. To find the HTML RGB values for many colors, see the Color Table in the MSDN Library. If you must match a specific color and you can’t find a match for the color online, you can use an image editing tool to sample a color and determine its HTML RGB value.

To test your changes, open Internet Explorer and enter the URL for Outlook Web App. If you’re testing the changes to the Default Web site on the Client Access server that is hosting the Outlook Web App virtual directory, you can test them by opening Internet Explorer and entering the URL https://localhost/owa.

Ee633483.note(en-us,EXCHG.141).gifNote:

The language selection page appears only the first time that a user signs in to Outlook Web App.

The following table lists the elements of the sign-in and sign-out pages and a description for each element.

Sign-in and sign-out page elements and their descriptions

Element to change
String to search for
Description

Background color of the Web browser window

body{background-color:#ffffff

The background color of the Web browser window. This controls the color of the window that borders the sign-in and sign-out pages.

Background color the sign-in and sign-out pages

Background: #ffffff

The background color of the sign-in and sign-out pages. If you change the background color of the graphics files, you should change the background color to match.

Warning text

wrng{color:#ff6c00;

The color of the warning text that appears when a user selects This is a private computer. On the existing Outlook Web App sign-in page, this warning text is orange and stands out well against the white background. If you change the background color of the sign-in page, you may also want to change the color of the warning text so that it’s readable.

Primary text color

select, table{color:#444444;}

The primary text color is black. It indicates options that can be selected and entry fields on the Outlook Web App sign-in page. Examples include the labels for the user name and password fields, and the text next to the security options. If you’ve chosen a light color for your sign-in pages, black will still work well for this text.

Show explanation/hide explanation

a{color:#ff6c00;

Link on the sign-in page that a user can click to show or hide the explanation of Private and Public sign-ins.

Explanation text

expl{color:#999999;

The color of the text that appears when the user clicks show explanation.

Description of the light version of Outlook Web App

disBsc{color:#999999;

When a user selects Use the light version of Outlook Web App, a short explanation about the light version of Outlook Web App is displayed.

After you’ve decided which elements you want to change the color of and identified the HTML RGB color values that you’ll be changing those elements to, use the following procedure to change the color of any element that is defined by a .css file.

  Change the color of an element

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Text editor" entry in the Client Access Permissions topic.

  1. Open logon.css.
  2. Use the table of sign-in and sign-out page elements included earlier in this topic to find the string that matches the element that you want to change.
  3. Replace the HTML RGB color value of the element that you want to change with the new HTML RGB color value that you want to use for that element.
  4. Save your changes and close logon.css.
  5. Test your changes by opening Internet Explorer and entering the URL for the Outlook Web App sign-in page.

Ee633483.note(en-us,EXCHG.141).gifNote:

If you’ve already opened the Outlook Web App sign-in URL, you can test your changes by deleting the temporary Internet files and refreshing Internet Explorer. To do this, click Tools, and then click Internet Options. On the General tab, under Browsing history, click Delete. Under Temporary Internet Files, click Delete files, and then click Yes when you’re asked whether you’re sure that you want to delete all temporary Internet Explorer files Click OK to close Internet Options, and then press F5 to refresh the sign-in page.

Customize the Outlook Web App Sign-In and Sign-Out Pages: Exchange 2010 SP1 Help

Exchange 2007 Messaging Records Management (Part 1) March 6, 2011

Posted by John Ruby in Solutions, Troubleshooting & Knowledge Bases.
add a comment

 

Exchange 2007 Messaging Records Management (Part 1)

Introduction

One major new feature of Exchange 2007 is that of Messaging Records Management (MRM). The main principle behind MRM is that it helps an organization with its legal compliance requirements, something that previous versions of Exchange aren’t particularly good at. It does this by placing the onus on the user to categorize their messages, leading to these messages being retained where appropriate. Obsolete messages are then removed. Sounds simple enough? In truth it is, although there are a few processes to understand and some terminology to become familiar with.

The MRM Process

As I just mentioned, with MRM users are able to categorize their own messages and ensure that these messages are retained. Where are they retained? One of the key components of MRM is a managed folder. There are actually two types of managed folder, namely managed default folders and managed custom folders. Managed default folders are based on folder names that already exist within users’ mailboxes, such as the Inbox or Sent Items, whilst managed custom folders are created by the Exchange administrators and are essentially additional folders seen within users’ mailboxes. They can be seen via Outlook and OWA and typically they cannot be deleted, renamed or moved. For example, Figure 1 shows how managed folders appear within the OWA client. Notice how, when right-clicking the folders, that the options to delete or rename the folders are dimmed.


Figure 1: Managed Folders In OWA

We’ll cover how you create these managed folders and how to set the retention settings as we go through this article. The important point to take away at the moment is that it’s the users that classify their messages, placing them into the appropriate managed folder either manually or via rules. If messages are placed into managed folders for retention purposes, it follows that there must be a process for removing unwanted content. MRM gives us a way to control unwanted content based on age or message type. We’ll also cover that as we go through this article.

You have already seen from Figure 1 what managed folders look like from within an OWA client. You’ll notice that the managed folder names in Figure 1 are all custom names that I created, hence these are referred to as managed custom folders. Look at Figure 2 below to see a list of the managed default folders that can be configured. Note that the Action pane has been removed from the Exchange Management Console (EMC) for clarity. To view managed default folders via the EMC, follow these steps:

  1. Run the EMC.
  2. Expand the Organization Configuration node and then click Mailbox.
  3. In the result pane, select the Managed Default Folders tab.

To view this information via the Exchange Management Shell (EMS), the relevant cmdlet is Get-ManagedFolder. This is shown in Figure 3.


Figure 2: Managed Default Folders


Figure 3: Results of Get-ManagedFolder

For the remainder of this article, let’s look at the first two steps of the five required to deploying MRM. In part two of this article, I’ll cover the remaining three steps.

Step 1: Create Managed Folders

Managed default folders are created automatically when Exchange 2007 is installed, although you can choose to create additional managed default folders if you wish. Creating managed custom folders is really easy, both via the EMC and via the EMS. Let’s go through the process of creating some sample managed folders and content settings as follows. Don’t forget, these are just sample folders to give you an idea of the process; they probably wouldn’t mean much in the real world!

  • Check users’ Inbox folders for items older than 90 days. Once found, these items are placed into a managed custom folder called Old Inbox Items where they are retained for a further 180 days.
  • Create managed custom folders that store documents for two different projects, namely Project X and Project Y. These documents are stored for 365 days.

The first thing to do is to create the new managed custom folders. Here’s how:

  1. Run the EMC.
  2. Expand the Organization Configuration node and then click Mailbox.
  3. Either right-click the Mailbox object and choose the New Managed Custom Folder… option, or choose the same option from the Action pane.
  4. The New Managed Custom Folder wizard appears which consists of the screen that you see now, plus the Completion screen. The first screen is shown below in Figure 4.


Figure 4: Managed Custom Folder Wizard

  1. On the first screen, the following information needs to be entered:
    • The Name field is the name of the managed custom folder as seen within the EMC and EMS.
    • The Display the following name… field is the name that users see within Outlook and OWA. This field is automatically populated with the same information that you type into the Name field, but you can change this field if you like. In my case, I’ve set both of these fields to Old Inbox Items.
    • There is an optional size limit that you can set on this managed custom folder. In my case, I set this to 1024KB meaning that each user gets allocated 1MB to this managed custom folder. This is obviously too low to be meaningful, as I entered this value to make it easy for me to simulate what happens when the storage limit is exceeded.
    • There is an optional field to enter descriptive information that is shown to the users within Outlook or OWA. Figure 5 gives an example of how this looks to the users in OWA, coupled with how the storage limit allocation is progressing.
    • Finally, there is an option to prevent users from minimizing the descriptive information in Outlook or OWA.
  2. Once all the relevant information has been entered, click the New button. The Completion page is then shown which also shows you the EMS commands to create this managed custom folder via PowerShell. The cmdlet used is:
    New-ManagedFolder -Name ‘Old Inbox Items’ -FolderName ‘Old Inbox Items’ -StorageQuota ‘1MB’ -Comment ‘Inbox items older than 90 days are placed here for your review.’ -MustDisplayComment $true

I’ve then repeated the above series of steps to create the Project X and Project Y managed custom folders.


Figure 5: Managed Custom Folder Comment

Incidentally, since I’ve mentioned the fact that you can set storage limits on the folders, you may be wondering what happens if you exceed these limits. Figure 6 shows you how the storage limit allocation comment looks when you’ve exceeded your limit. Figure 7 shows you the warning message you receive when attempting to add additional items to the folder that has exceeded the limit. These are how the messages are seen in the OWA client.


Figure 6: Managed Custom Folder Storage Limit Exceeded Comment


Figure 7: Warning When Storage Limit Exceeded

Step 2: Create Managed Content Settings

The next piece of our MRM jigsaw is the managed content settings. Managed content settings actually apply to either managed default folders or managed custom folders like the folders we just created. In our case, we want to apply settings to the default Inbox folder as well as our three managed custom folders which means we’ll be setting three different managed content settings (both ‘project’ folder content settings are essentially the same). Managed content settings allow you to perform various options such as moving items to the Deleted Items folder or your chosen managed custom folder, or perhaps permanently deleting the items. It follows that, since managed content settings apply to managed folders, you must either target the managed default folders or have created at least one managed custom folder before you can create managed content settings. Here’s how to create our managed content settings for the default Inbox folder:

  1. Run the EMC.
  2. Expand the Organization Configuration node and then click Mailbox.
  3. Select the Managed Default Folders tab and you will now see the managed default folders list as shown above in Figure 2.
  4. Highlight the Inbox managed default folder and then either right-click it and choose the New Managed Content Settings… option, or choose the same option from the Action pane.
  5. The New Managed Content Settings wizard appears showing the Introduction screen. This is shown in Figure 8. Let’s examine the options that have to be configured:
    • In the Name of the managed content settings… field, enter a meaningful name that will be seen in both the EMC and EMS. I’ve chosen to enter ‘Inbox items older than 90 days’.
    • In the Message type drop-down list, choose the type of items that will be affected. Choices are All Mailbox Content, Calendar Items, Contacts, Documents, Faxes, Journal Items, Meeting Requests Responses and Cancellations, Missed Calls, Notes, Posts, RSS Items, Tasks and Voicemail. Since I want everything older than 90 days to be affected, I’ve chosen All Mailbox Content.
    • We require message retention to be set, so the Length of retention period (days) check box is selected and a value of 90 added.
    • Since the above option has just been selected, it’s now possible to configure when the retention period starts. I’m interested in ensuring that the retention period starts when the messages are delivered, so I’ve left it at the default option. The other option is When item is moved to the folder.
    • It’s now also possible to specify the Action to take at the end of the retention period. I’ve chosen the Move to a Managed Custom Folder option, clicked the Browse… button and then selected the Old Inbox Items managed custom folder previously created. The other options here are Move to the Deleted Items folder, Delete and Allow Recovery, Permanently Delete and Mark as Past Retention Limit.
    • Once completed, this screen looks like the one shown in Figure 8.


Figure 8: Managed Content Settings Wizard

  1. Clicking the Next button takes you to the Journaling screen, where it’s possible to forward copies to an alternative address. It’s possible to pick any type of mail-enabled recipient here, such as a mailbox, distribution list or contact. I’ve not selected this option in this example.
  2. Clicking Next takes you to a configuration summary screen, followed by the Completion screen that once again shows you the EMS command to create this configuration via PowerShell.

The cmdlet used is:

New-ManagedContentSettings -Name ‘Inbox items older than 90 days’ -FolderName ‘Inbox’ -RetentionAction ‘MoveToFolder’ -AddressForJournaling $null -AgeLimitForRetention ‘90.00:00:00’ -JournalingEnabled $false -MessageFormatForJournaling ‘UseTnef’ -RetentionEnabled $true -LabelForJournaling ” -MessageClass ‘*’ -MoveToDestinationFolder ‘Old Inbox Items’ -TriggerForRetention ‘WhenDelivered’

It’s worth bearing in mind that once you’ve created your managed content settings, they appear below the relevant folder they are associated with as shown in Figure 9. Once again, the Action pane has been removed for clarity.


Figure 9: Content Settings Linked To Managed Default Folders

I’ve then proceeded to create additional managed content settings for the Old Inbox Items, Project X and Project Y managed custom folders. The ‘Old inbox items older than 180 days’ managed content settings configuration applies to all folder content and permanently deletes all items in the Old Inbox Items folder that are older than 180 days, whilst the ‘Documents relating to Project X’ and ‘Documents Relating to Project Y’ managed content settings apply only to documents and delete items older than 365 days. As you can see, things are flexible to suit your needs.

I want to close part one of this article by drawing your attention to the Entire Mailbox managed default folder that you may have noticed in Figure 9. This can be used to apply managed content settings to all folders within a user’s mailbox, although managed custom folders and managed default folders already linked to a managed folder mailbox policy are excluded. I’ll be covering managed folder mailbox policies in part two of this article.

Exchange 2007 Messaging Records Management (Part 1)

Applying Managed Folder Policy to more than one user | Exchangepedia March 6, 2011

Posted by John Ruby in Solutions, Troubleshooting & Knowledge Bases.
add a comment

 

Applying Managed Folder Policy to more than one user

by Bharat Suneja on May 16, 2007

Scenario: You have a Managed Folder Mailbox Policy called Policy-DeletedItems90Days. The policy has Managed Content Settings to permanently delete items in the Deleted Items folder after 90 days.

You can easily apply this Managed Folder Mailbox Policy to a single user using the Exchange console, as shown in Figure 1.

Screenshot: Applying Managed Folder Mailbox Policy using the Exchange Management Console
Figure 1: Applying a Managed Folder Mailbox Policy to a user using the Exchange Management Console

A Managed Folder Mailbox Policy can also be applied to a mailbox using the following shell command:

Set-Mailbox “Foo User” -ManagedFolderMailboxPolicy “Policy-DeletedItems90Days”

How do we apply this to more than one user? By using the Get-Mailbox command to fetch a bunch of mailboxes — either all mailboxes in the Organization, or all mailboxes in a particular Organizational Unit (OU), or all (mailbox-enabled) users who are members of a particular distribution group, or by filtering mailboxes based on other user parameters. The mailboxes returned can then be piped to the Set-Mailbox command.

To apply a Managed Folder Mailbox Policy to all (mailbox-enabled) users, we need to get a list of all mailboxes, and pipe it to the Set-Mailbox command:

Get-Mailbox -ResultSize unlimited | Set-Mailbox -ManagedFolderMailboxPolicy “Policy-DeletedItems90Days”

To apply the policy to all mailboxes in a particular OU, e.g. an OU called Sales, we restrict our Get-Mailbox query the Sales OU:

Get-Mailbox -OrganizationalUnit “Sales” -ResultSize unlimited | Set-Mailbox -ManagedFolderMailboxPolicy “Policy-DeletedItems90Days”

Apply a Managed Folder policy to members of a Distribution Group

When applying the policy to members of a Distribution Group, remember that Distribution Group members can include recipient types other than mailbox-enabled users (e.g. mail-enabled users, Contacts, other Distribution Groups, Public Folders, etc.) which can’t have a Managed Folder Mailbox Policy applied. To apply the policy to all mailbox users who are members of a Distribution Group called DL-Sales, we will need to get members of the Distribution Group using the Get-DistributionGroup command, filter the result to get only mailbox-enabled users, and pipe it to the Set-Mailbox command:

Get-DistributionGroupMember “DL-Sales” -ResultSize unlimited | where {$_.RecipientType -eq “UserMailbox”} | Set-Mailbox -ManagedFolderMailboxPolicy “Policy-DeletedItems90Days”

One logical question after the last example — can I do this with Security Groups (that are not mail-enabled) instead? You cannot get the group membership of a Security Group as easily as you can get the members of a Distribution Group. Unfortunately, Exchange Shell does not have any equivalent of the ADSI provider. (You can search the web for shell scripts to enumerate security group members – Bharat)

Avoid the confirmation prompts when applying a Managed Folder policy

When applying a Managed Folder Mailbox Policy, you run into 2 prompts. The first one is the default confirmation prompt produced by Set-Mailbox. This is cmdlet saying, “Hey, something changed! Are you sure you want to do this?”, and prompts you for a confirmation as shown below:

Confirm
Are you sure you want to perform this action?
Setting mailbox “exchangepedia.com/People/foo user1″.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is “Y”):

You can avoid it by simply using -Confirm:$false in the command.

Next, you will run into the confirmation prompt produced when applying a Managed Folder Mailbox Policy. This is the cmdlet realizing, “Hey, this one’s a serious change — you’re applying a MF policy! Are you really, really sure? And btw, it’d be a good idea to block legacy Outlook clients!”. The resulting prompt is shown below:

Confirm
When assigning a managed folder mailbox policy with managed custom folders to the mailbox “exchangepedia.com/People/foo user1″, Outlook clients older than Outlook 2007 do not have all available client features and clients older than Outlook 2003 SP2 are not supported. You may use the “Set-CASMailbox” task to enable client version blocking. Are you sure you want to assign a managed folder mailbox policy to this mailbox?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is “Y”):

To override this prompt, you’ll need to use the ManagedFolderMailboxPolicyAllowed switch. The command from the above example will thus look like this:

Get-Mailbox -ResultSize unlimited | Set-Mailbox -ManagedFolderMailboxPolicy “Policy-DeletedItems90Days” -ManagedFolderMailboxPolicyAllowed -Confirm:$false

A default Managed Folder policy for new users

A related frequently asked question — Can you have a default Managed Folder Mailbox Policy that’s applied to new mailboxes automatically? There’s no built-in way to specify a policy as the default policy for all users or new users at the time of account creation. However, you can use the Windows Scheduler to schedule a script or command to run on a schedule and apply the required policy to users. For example:

Get-Mailbox -ResultSize Unlimited -Filter {ManagedFolderMailboxPolicy -eq $null} | Set-Mailbox -ManagedFolderMailboxPolicy MyPolicyName -ManagedFolderMailboxPolicyAllowed -Confirm:$true

Why not use LDAP filters?

That’s fine, you say, but you really liked the Exchange 2003 way of applying a Recipient Policy, using LDAP filters. It allowed you to use pretty much any attribute you chose to filter on. In Exchange 2007, there’s no built-in way of using LDAP filters to apply a policy.

Having said that, it’s not such a great idea to apply message retention policies based on an LDAP filter, or at least not in a manner similar to Exchange 2003. For instance, if you’re using a particular attribute to filter on, such as department, or group membership, simply changing the attribute or group membership could change when and how a mailbox user’s messages are retained or purged. If you have multiple overlapping Recipient Policies, at times it’s difficult to determine which policy is applicable to a user.

Exchange 2007 offers a simpler and deterministic behavior— by making the policy a user attribute. A policy explicitly associated with a user allows you to instantly determine which policy applies, with no ambiguity. It’s also auditable, and reportable

The automation is provided by PowerShell. Of course, you can simulate Exchange 2003′s Recipient Policy behavior by using an OPATH filter with the Get-Mailbox cmdlet. (However, if you still need to use an LDAP filter, Nick Smith shows you how in Applying Managed Folder Mailbox Policies via LDAP Filters).

Applying Managed Folder Policy to more than one user | Exchangepedia

Applying Managed Folder Mailbox Policies via LDAP Filters – Nick’s Unified Communications and Scripting Blog – Site Home – MSDN Blogs March 6, 2011

Posted by John Ruby in Solutions, Troubleshooting & Knowledge Bases.
add a comment

 

Applying Managed Folder Mailbox Policies via LDAP Filters

 

In Exchange 2003 Mailbox Manager Policies could be applied to subsets of mailboxes using LDAP filters the same way Recipient Policies were applied.

In Exchange 2007 this behavior changed. Mailbox Manager Policies are now called Managed Folder Mailbox Polices and they are assigned on a per user level. This new methodology allows more granularity and eliminates some of the confusion about which policy is being applied.

However, in some cases the ability to apply these policies via LDAP filters is desired and the change is cumbersome. If you prefer the filtered method for applying policies, you can write a script using the PowerShell function below:

function Apply-FilteredManagedFolderMailboxPolicies ($LDAPFilter, $ManagedFolderMailboxPolicy)

{

$root = [ADSI]”

$searcher = New-Object System.DirectoryServices.DirectorySearcher($root)

$searcher.Filter = $LDAPFilter

$searcher.PageSize = 500

$users = $searcher.findall()

foreach ($user in $users){

$UserDN = [String] $user.properties.distinguishedname

if ($UserDN -notlike "*SystemMailbox*"){

$mailbox = get-mailbox $UserDN

if ($mailbox.RecipientTypeDetails -ne "LegacyMailbox"){

write-host "Updating: $UserDN"

Set-Mailbox -Identity:$UserDN -ManagedFolderMailboxPolicy:$ManagedFolderMailboxPolicy -ManagedFolderMailboxPolicyAllowed:$true

}

}

}

}

This function will search your current domain for user accounts that match the supplied LDAP filter. For each user returned, the account is checked to ensure that the mailbox is hosted on an Exchange 2007 server and will set the Managed Folder Mailbox Policy as desired.

Combining with the LDAP filters you have already created for your existing Mailbox Manager Policies, you can easily write a script to apply the appropriate policies via filters.

#Usage:

#Apply-FilterdManagedFolderMailboxPolicies $LDAPFilter $PolicyName

# Default Policy

Apply-FilteredManagedFolderMailboxPolicies "(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))" $null

# Delete after 180 days policy

Apply-FilteredManagedFolderMailboxPolicies "(&(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) )))(objectCategory=user)(memberOf=CN=Delete After 180 Days,CN=Users,DC=domain,DC=com)))" "180 day policy"

When writing the script, remember that the precedence of your policies should be lowest to highest. The first policy you should apply should be your default policy (or $null if you don’t want one) and the last policy should be your most restrictive filter with the highest precedence.

In this example, the default action is to no assign policy. The “180 day policy” is applied to the members of the "Delete After 180 Days" group.

When using groups to apply policies it is important to remember that there must be a default policy in your script so that once a user is removed from the defined group, the existing policy applied will be updated to the default policy.

About LDAP Filters

To get the LDAP filters used with existing Mailbox Manager policies simply open the policy and copy the text in the Filter Rules: textbox. Paste this filter encompassed in quotes into your script and you will be good to go.

If you want to manually create your own LDAP search string you can use the information at Creating an LDAP Search String to get you started.

If you prefer the GUI method open Active Directory Users and Computers, right-click the Saved Queries folder, select New, and Query. Click the Define Query box and select Users, Contacts, and Groups from the drop down box. On the Advanced tab select the attribute you would like to use from the filter from the Field box. At the very minimum you should add the following filters to start:

User: E-Mail Address                 Starts with *

User:Exchange Home Server      Starts with *

Scheduling the Script

To ensure user policies are updated correctly based upon the filters, you must schedule this script to run sometime before the Managed Folder Assistant runs on the servers. Therefore is the assistant runs daily at 5am, the script should run daily at 3am.

Applying Managed Folder Mailbox Policies via LDAP Filters – Nick’s Unified Communications and Scripting Blog – Site Home – MSDN Blogs

RD Gateway/Web Access Outside the Firewall « Bitz March 2, 2011

Posted by John Ruby in Solutions, Troubleshooting & Knowledge Bases.
add a comment

 

RD Gateway/Web Access Outside the Firewall « Bitz

RD Gateway/Web Access Outside the Firewall

WebAccessAndGateway

I recently had the opportunity to work with one of Microsoft Windows Server 2008 R2’s neatest features: Remote Desktop Gateway (RD Gateway) and Remote Desktop Web Access (RD Web Access). If you aren’t familiar with these features, check out a brief summary here.

The setup is fairly straightforward, as outlined here and here. However, I did run into an issue that slowed me down a bit. The solution to this was not documented in the step-by-step guides or on the Microsoft Technet website. If anyone knows otherwise and I’ve overlooked this, as always, please provide the appropriate links in the comments.

Problem: Not able to connect to a Remote Desktop or Remote App program from outside the firewall. Inside the firewall, everything worked like a charm. The network firewall (Cisco router) was configured to allow the appropriate traffic (port 443). Disabling the Windows Server 2008 R2 firewall did not make a difference.

Auth Error

Solution part 1:

Add computer account to domain “IAS and RAS Servers” group

IASRAS Group Membership

Solution part 2:

You should also be sure to configure the default Remote Desktop Gateway server for RD Web Access. Otherwise you could run into issues with the RD Web Access not knowing which RD Gateway to use (even if both roles are installed on the same server!).

  1. Open up “IIS Admin” console from the “Administrative Tools” menu.
  2. Navigate to the default web site and configure the “Application Settings” for “Default Web Site\RDWeb\Pages“.
  3. Change the following setting:

DefaultTSGateway” = [fqdn of Internet accessible TS Gateway]

Note: make sure this is also the server name listed on your SSL certificate.

DefaultTSGateway_AppSettings