![]() |
|
|
| Become a Columnist Microsoft Exchange Site Microsoft Support SiteMSDN Exchange Site | ||
|
|
Web GAL Mod Com object - Allow a staff member to modify phone numbers of all people in their department/office.Introduction Download Files Keeping address list information (or Active Directory user information in Exchange 2K) up to date and accurate is always a constant struggle in large Exchange and W2K networks. Utilities such as GAL mod and Web Gal mod where a great leap forward as they provided the user with a simple interface they could update their own information with. Unfortunately a lot of people are lazy or no matter how simple you make it they still can't seem to use or remember to use these utilities to update their phone numbers when they change. Or more importantly they believe themselves too important to stoop to changing their mobile number in the mail system. In most organizations however there are usually one or two administrative/reception people per office or department who's job it is to look after the general running of their department and do all that ugly paperwork and other jobs most people don't want to do. These people more often then not have there own lists of information and phone numbers of the staff in their office/department and are always the first people to know if a phone number/address changes. In active directory you could delegate rights to these people to allow them to modify objects within certain OU's but this is time consuming and may possibly not match the way you have set up your OU's. So what this app is designed to do is to display all the users from the Department (or Office if you like) the (admin/reception) staff person belongs to and then allow them to modify any of the phone/address details of the users within their department from a web page. All modifications and queries are performed though a Com object on an IIS server that runs under the context of a user that has rights to view and write to phone attributes of all users in your Active Directory Tree. This effectively eliminates the need to delegate rights to the users to modify Active Directory objects. Security can still be implemented using NTLM on the ASP pages to restrict which users have access to them and also by the fact the Com object only returns information based on the user that is querying it and also controls which properties can be updated. How it works As I mentioned above this idea uses a Com object running under a different user context to modify Active directory properties on a users behalf. Com objects to me sounded very complicated at first but after a bit of research I found quite an easy way to build Com objects in VBS . I've written another article that details the steps necessary and links for the software you will need to build and register the Com objects for this article (don't worry its all free). Installing ASP pages and Com object for use What I recommend with these ASP pages is to create a new directory on your web server (eg galmodweb) copy these pages into this directory and then go into the Internet Services Manager and view the properties of the directory. You need to allow execute permissions for scripts and executables on the general page. And then go into the directory security tab and select the authentication control button and remove all other security options except NTLM. This will mean you will have to use a browser that supports NTLM to authenticate to use these web pages (IE) and you need to remember that you can't proxy NTLM authentication so it needs direct browser access (eg needs to be in your browser exceptions). The ASP pages rely on this security to be able to grab the userID so it can perform the query to only return users in that persons department. For details on installing and registering the Com object for use please see my other article note this article details building a new Com+ application from scratch. You can use the file I've included in the download (remember to change the domainname variable in the Com object code) instead of building your own if you do this you still need to do the registration and creation of the Com+ wrapper part of this article. Query User Asp page This first Active Server Page basically shows the user all the people that are in their department and offers them a link they can click for each user if they wish to make changes to a particular user. It does this by first creating an Instance of the GALMOD object, next it determines the username of the currently logged on user by using ADSI (you could also use the session variable here and parse out the domain name, i find using ADSI easier in a pure 2000 environment). It then calls the ShowGal function in the GALMOD com object submitting the username that was determined earlier as a parameter. <%@ Language=VBScript %> Inside the GALMOD object Inside the GALMOD Com object the ShowGal function starts and the first thing it does is query Active directory for the Department that the user who issued this request belongs to. This information is then used to query active directory to create a recordset of all the users within the requesting users department. This record set is then passed back to the ASP page to be displayed to the user for more detail on this process have a look at my other article which goes though creating a recordset in ADO for Active directory using LDAP and ADSI. The rest of the ASP page deals with displaying the result set to the user and providing the edit link for each entry in the result set. The edit link uses HTTP query values to pass information from the display page to the update form to allow for modification. (This information is passed on the URL string) If you wish to modify the way this GALMOD object works to say return all the users within a users office please see the section "Changing the Queries defined in the GALMOD Com object" in my other article. Modify User Detail ASP page The modify user detail page displays the user information in a form that can be updated by the user, the form fields are filled out by using Request.Querystring to retrieve the values sent from the query user asp page. Note there is a restriction with the amount of data you can pass using Request.Querystring I believe its about 1024 characters if you do run into a problem with this you might need to look at doing a form submit from the query user page. When the user submits the form its submitted to the Confirm update asp page. Confirm Update ASP page The confirm update ASP page creates a instance of the GALMOD com object, retrieves all the form fields that where submitted into script variables then calls the updateuser function in the GALMOD object with the script variables as parameters. It then accepts a success or error back from the GALMOD com object and displays the result to the user. Inside the GALMOD object Inside the GALMOD Com object the updateuser function starts and the distinguished name of the user which was passed as one of the form parameters is used to bind to the user object to set it up for updating. The rest of the function goes though and checks to see if any data was entered in the form field. If so it updates the active directory property using the put statement. At the end of the function the setinfo is called to commit the changes to the user object. Testing and Troubleshooting problems If you keep receiving general access denied errors when attempting an update it could mean that your Com object is not configured properly or the account which it is running under does not have rights to the properties its trying to update in active directory. You may also receive this if you are trying to modify a user that has administrative rights in your domain. If the user the Com object is running under has only been giving modify property rights they will not be able to modify the properties of a user with Administrative rights. So if your testing this make sure you are trying to modify a user with normal rights and not an administrative user. Customising this app to include other Active Directory fields Of course your not just limited to only changing things like phone numbers by changing the methods and queries used in the Galmod Com object you can create different display and update pages. And as long as the user you are running the GALMOD com object under has rights to modify these active directory properties it should work okay. There are exceptions however take the Manager field for example the manager field in Active directory stores the Distinguished Name of the account that is the Manger of this active directory object. So from a user perspective this is not practical for them to update unless you find a way to present this information to the user in a different way and then do a conversion when they submit the update (maybe a future article). Running these Pages on Exchange 5.5 If you are running Exchange 5.5 and you are using Active Directory and you have two way Active Directory Connector replication setup with Exchange this app should work fine without any modification as long as you implement the Com Object on a Windows 2000 server. If you are still running NT4 the concepts in this article should work but the code in the GALMOD object will need to be rewritten. I am currently looking into this so I may post an NT4/Exchange 5.5 version in the future. |
|
|
|
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