Redirection checking

Status
Not open for further replies.

htd01

Member
Outlook version
Outlook 2010 32 bit
Email Account
Exchange Server
Situation:

I use resource management in exchange 2010, however, we now have several rooms that are "Partitionable" rooms; that is, they can either be split, or not. The best way to handle this kind of situation, according to microsoft, is redirecting. However, they haven't given me any indicaction on whether or not I can actually test for redirection (so I avoid redirecting in perpetuity). I was wondering, since most redirection sets up the new address as the only recipient from the server, would this be a good test to use (if I am only recipient test in OWA rule)? If so, I can finish up. Thank you. I'll check this later of course, but for now, I thought I'd ask.
 
I found out that there is an Auto-Forwarded flag set to true even if you utilize the Redirection. If you do it internally, the system marks it as a forward rather than a simple redirect. This is the test I will use (is type: autoforward) for the exception handling. Thank you for your time. I tried checking for the only recipient, but some others are redirected as well as a cc, so this will not work (it will only work if you redirect to only one recipient). However the auto-forward flag reads as TRUE. This can be utilized to separate those that are already forwarded.
 
I found also that if you have multiple recipient boxes that redirect to one another, it's a good idea to have that end by checking for their names in the CC field (optional Recipients). This as an exception stops the cycle completely, and they are only redirected to once. Those that are booked as a redirect will still show up in the optional field, so it's best to forget that field entirely. IF you must use a form of redirect for an actual person (i.e. for a BCC or a CC), I suggest you use the Forward as Attachment option. You don't have to specify a TO if you specify a cc or a bcc. Then they should see the event and all other recipients, but they will not be seen until they respond in the affirmative. (optionals and resources are only visible to those with access to that information on the calendar that sent the message. If you only allow subject view, the location is included, along with time, but the rest is left out; that has been my exp, but there may yet be a setting or two I'm overlooking).
 
Correct - forward as attachment has a lot of advantages for mail and calendar.
 
I haven't gotten the forward as attachment to work in the facility and equipment boxes. But that's mainly auto-processing issues. A redirect works, however, and it sets the flag for auto-forward to TRUE. I checked this out online and found that redirected emails are an old spammer trick, so instead of only passing the email through with the same header info, many clients and server systems that offer redirect will attach a tag or flag to the header, noting that it was redirected; some also add the redirection pathways. Exchange just wipes the header of all but the basic "From" information pointing to the original sender, then tags on the auto-forward flag set to true. This allows for simplistic use internally, and when using the "I'm the only Recipient" test, can produce results, so long as there are no other rules redirecting, sending or copying. When this is the case, it's best to check for the auto-forwarded flag first. In order to prevent this from repeating a send, you should add the exception for the current recipient being in the CC list (which is optionals for meetings). Just thought you'd like to know.

PS

I've done some whacky partitioned-room management as well as multipurpose room\equipment management with these rules. If you'd like I'll send a basic list of what's necessary to make them work properly.
 
Yes, your list of what's necessary would be useful to others who read this thread. If you're interested in writing a guest column, email me at diane @ slipstick dot com.
 
I started work on the list. I'll post it here as soon as I finish. Should be later today or early tomorrow; but I have to go to work right now.
 
Premise:

1 big room, 2 partitions (options are to use whole room or partition as necessary)

result:

3 rooms needed to make this work excellent

Partition A, Partition B, Partition AB

You can tell which is which right?

Rule for a and b partition (the two partitions of the room):

When mail arrives and Its of the type: Meeting request
ThenCategorize as cc’d

And Redirect to Partition AB
Exception if its of the type autoforwarded

Exception if my name is in the CC list

Rule for AB is the same except for the redirect:

When mail arrives and Its of the type: Meeting request
ThenCategorize as cc’d

And Redirect to Partition A and Partition B
Exception if its of the type autoforwarded

Exception if my name is in the CC list

Rule for all of them (after the other rule):

if my name is in CC list
then categorize as cc'd

Rule for all users (optional rule to block out the extra messages sent when redirection occurs):

-----When mail arrives and its of the type Meeting Response

-----AND its from Partition AB or Partition A or Partition B

-----And Category is cc’d

-----optional and (header test for denial response; Response = deny or similar Check one yourself to find out; book a room twice and find the response code in the rejection message.)--------this test will cause it to delete only denial responses

then delete message

I dislike using the whole optional rule. Things change. If I book only a partition, but I want to use the whole room because it looks available, and I make that change after somebody else books the other partition, I won't know there is a problem until it's too late. However, If I see a room in optionals that doesn't respond, I know it may be due to the fact that it's booked. If I'm more illiterate with the system, I won't notice that. It's better to get the initial message and make the change right away when I can.

However, one other way to make sure that this works is to set the Whole Room (partition AB) to let Everyone request permission when unavailable, which will add the Tentative marker, and book the room when somebody else removes their booking. Adding this rule without the optional test will then work as expected, and while they attempt to grab the room, it will only reply as tentative, showing them that it is unavailable. This requires some training to remind the users that tentative and unavailable are the same thing for rooms, so either way you end up with some training. I like the initial way best for small numbers of partitions, 2-5, and I like that last one better for numbers larger or more complex than that.
 
New rule edits:

Forget marking those redirects from partition AB to either of the other rooms, and forget processing those. You want the accept and denial messages to process from the partitions so you know if any are available later, if you try to book the whole room. Set the AB (whole room) to mark pending as tentative, then set it so that all users may be auto processed on available, and may request if unavailable (auto process in policy, and make requests out of policy). After that, you can use the following rules to sort out the rest of the logic; apply them to users:

When mail arrives and it is of type meeting response

and it is from partition AB

and test shows it as Tentative (header test)

delete message

exception if message category is CC'd

Same beginning as before up to header test...

and category is CC'd

and header test shows declined or tentative

delete message

Now you will block tentative messages from partition AB and only the partitions that are available will respond positively, letting you know of their usage.

Why a Tentative processing rule?

When you book Partition A, and somebody else books Partition B later, you already have the whole room marked (booked by CC), so if you remove your booking to a new room and remove the whole room marker, the Whole room will already have sent a denial to the B-booking, and will be available once your event is removed, even though B is booked. If it is marked tentative from B forwarding, it will respond with a positive value as soon as the booking from A is listed. Anybody trying to book the whole room won't get the tentative messages or denials when a part is already booked, and instead they will get messages from the partitions about which are available and which are not. The logic is complete for internal use and when you make a note that the room is partitioned, and the partitions will respond as well as the whole room, you can let external users know what's going on.

**If you set up a transport policy to mark the external user and send to an internal box first, you can remove any doubt by only allowing the partitions to respond (have it send the whole room responses to an internal box that deletes the message completely, and only allow the partitions to respond; if all respond positive, the user knows the whole room is available and is booked). This is considerably more involved an not recommended unless you are proficient with the shell. You can add the rules to all users by writing a script in notepad for all of them to add the rules in reverse order (the first rule is added last).
 
Another adjustment.

You can have auto replies generated for Tentative messages, and then have them delete. The auto-reply is in this form:

User Rule:

when Tentative recieved, send to hidden room as a forward (not a redirect), then delete the tentative

Hidden Room rule (hidden room can be equip rule, I suggest a name with a dev_ prefix or suffix for easy search later):

First set auto-reply indefinite, and create your denial message

Then create a rule with the following attributes:

Delete all messages

unless from a DEV

The only downside left is that the AB whole room may or may not show the tentatives (even when there are no definites set the tentatives are still there), and if it does, it shows all of them (if 30 people want that room, they all get a message about it being denied, but they may not all make the adjustments needed to the event, and the denial isn't linked to the event. However, you have now taken this room out of the loop completely, making one rule for all users to use (can be shell scripted to them) and one rule for a single room (equip account is better in 2010, it doesn't add to any lists, and you can hide it later).

Make sure AB (Whole room) Rules properly redirect on a user direct send, and do not do so on a redirected send.

The denial message will be sent, but again, not all users will know what event it corresponds to. A way around it is to forward the user a copy of the tentative message beforehand or not delete it, so that the two messages are recieved almost in tandem. That will reduce confusion and link the user to the event from the first message, so you can apply that information in your denial message, along with some advice:

This Whole Room is denying that it is available, even though other partitions may be available. Check your email box for their acceptance, and you can add them to your resources if you wish. See the email before this one (noted by the Forwarded Message Information in this email) to see which event this corresponds to.

It is adviseable to remove the affected room from your event, without sending an update, after the event has been sent to all other people attending. When the room replies with an ACCEPTED message, be aware that it may not be open, it is only acknowledging that you are the first in line. You may wish to check the opposite Partition(s) of the room first by checking their availability, and, if empty, you may fill the entire room by inviting it using the OPTIONAL bar. It is also advised that you move your first elected partition to that bar, in this instance, and the whole room to the Resources list. This will change the location bar for you.

Thank you.
 
Status
Not open for further replies.

Similar threads

Back
Top