Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site

       How did you like this article? Please vote and let us know.          

Subscribe to OutlookExchange
Anderson Patricio
Ann Mc Donough
Bob Spurzem
Brian Veal
Catherine Creary
Cherry Beado
Colin Janssen
Collins Timothy Mutesaria
Drew Nicholson
Fred Volking
Glen Scales
Goran Husman
Guy Thomas
Henrik Walther
Jason Sherry
Jayme Bowers
John Young
Joyce Tang
Justin Braun
Konstantin Zheludev
Kristina Waters
Kuang Zhang
Mahmoud Magdy
Martin Tuip
Michael Dong
Michele Deo
Mitch Tulloch
Nicolas Blank
Pavel Nagaev
Ragnar Harper
Ricardo Silva
Richard Wakeman
Russ Iuliano
Santhosh Hanumanthappa
Shannal L. Thomas
Steve Bryant
Steve Craig
Todd Walker
Tracey J. Rosenblath

 

 
 

Email Policy Acceptance Com Object - Enable/Disable a User's mailbox until they have accepted the company's Email policy.     Download files

As an email administrator one of the constant battles is to convince the users of the email system that they should use it in a responsible and respectful manner. Acceptable use policies are something that a lot of companies use to provide a set of rules to their employees that dictate how they should use the Internet and Email have a look at www.emailpolicy.com for some samples (this is a really good site). A few companies also implement a pop up application when users log on to signal they accept these terms before they can use the PC. The following is a method that I came up with that runs along the same line but is more specific to email. This is mainly aimed at new users to ensure they understand what the acceptable user policy is for email before they can start using the email system. It does this though using a Com object which provides a way of disabling the ability for a user to receive and send email until they have accepted the companies Email Acceptable use policy. Note this is not something that you would do every time someone logs on but its more aimed at a new user the first time they log into outlook . What that user will find in their inbox is one email that directs them to a web page that displays the Companies email policy and they will then need to accept this policy before they can use their email. What happens at the backend is there is a Windows Script Component Com+ object that runs under evaluated privileges that once the user has accepted the email policy it will remove the restrictions from the users active directory account. As  part of the process it will also send a copy of the policy to the user in an email and CC the HR department to signifies that the user has accepted the policy. Note: This does not replace a signed email policy document which will always be more legal binding then something electronic( but don't ask me I'm a techie not a lawyer)

How it works

Disabling a Users ability to send and receive email without disabling the mailbox

As with most things in IT there are multiple ways to achieve something like this the following is just one example.

Stopping someone receiving email for everyone bar the administrator (or other selected account)

Within Exchange if you want to limit who can send an email to a users mailbox this can be done via Delivery Restrictions from the Exchange General Tab in AD -Users and Computers. Within Delivery restrictions is a section called message restrictions which allows you to either limit who can send messages to this mailbox or who cant. (By default a mailbox will allow everyone to send and receive).  Within Active Directory the information that relates to who is allowed to send this user email is in the authorig active directory attribute. So what the Com+ object does is using ADSI it modifies the authorig attribute by either adding a user doing a Put or clearing this attribute using a Putex ADS_PROPERTY_CLEAR. Have a look at this Qbase as a reference.

qsting = "LDAP://" & rs.fields("distinguishedName")
set objUser = GetObject(qsting)
objUser.Put "authOrig", "CN=administrator,CN=Users,DC=yourdomain,DC=com"

 The one thing to note about the authorig active directory attribute is its a multi-valued attribute which means if you already have something in this attribute that you want to keep then you should use putex instead of put. eg

objUser.Putex 3, "authOrig", array("CN=administrator,CN=Users,DC=yourdomain,DC=com")

Once you have added this user to the authOrig attribute then this user will become the only person capable of sending email to this mailbox anyone else who tires will receive a permission denied NDR. (you need to use the DN of the user which can be obtained though using Adsiedit)

Stopping Someone Sending Email

This is a little bit trickier then stopping someone receiving email one of the most direct methods would be to change the permissions on the mailbox object itself. I'm not to keen on doing this for a number of reasons so I found another method that's easier to implement and manage. The method I used  is if you set the sending message size limit in the the Delivery Restrictions from the Exchange General TAB in AD -Users and Computer to a value of 1 KB which is the lowest you can set it to this will pretty much disable the users ability to send email (or more accurately they will only be able to send email that is smaller the 1 KB). Within Active Directory the Active Directory attribute that holds this information is called submissionContlength. So using ADSI what the Com object does is sets the value to 1 using a "put"  to restrict the user and once the user has accepted the policy it clears the property using a  Putex ADS_PROPERTY_CLEAR to clear this attribute.

objUser.Put "submissionContlength", 1
objUser.setinfo

To clear

objUser.PutEx 1, "submissionContlength", 0
objUser.setinfo

You could add a second level if you wanted to make sure they don't sneak any messages out that are smaller then 1 KB to the Internet. If you have a SMTP connector setup you can add the user to a group and then configure the Internet connector to reject mail from this group. I haven't gone this far as usually a 1 KB sending limit is good enough to stop most people (or at least really annoy them).

Why use a Com+ object

The main reason for using a Com+ object is that I want the user to be able to initiate a process that will have rights to modify their own mailbox Active Directory properties which they would not normally be able to modify with their normal access rights. The Com+ object is setup to run under an account that has these rights to modify these two Active Directory properties. For information on Building COM objects for NT and Exchange using VBS have a read of my other article.

Next Page Mailperm.wsc Com Object

Download files


Disclaimer: Your use of the information contained in these pages is at your sole risk. All information on these pages is provided "as is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Pro Exchange. OutlookExchange.Com and Pro Exchange shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

© Copyright Pro Exchange, Inc., 2006