This is a test of Windows Live Writer. Wonder if it will work with my own cBlogs site. Have to check that once I can get my VMWare server backup up after the last thunderstorm.
Monthly Archives: August 2006
Testing Exchange ActiveSync with Internet Explorer
1. Open Internet Explorer. In the Address bar, type https://published_server_name/Microsoft-Server-Activesync, where published_server_name is the published name of your OWA server (the name your end users will type).
2. Type the user name and information that you want to authenticate.
3. If you receive an Error 501/505 “Not implemented” or “Not supported” error message, Exchange ActiveSync is working properly.
Exchange, SharePoint Services and ActiveSync Administration…
Running Exchange 2003 and SharePoint Services on the same machine can be a challenge, as is well documented:
I recently tried to accomplish this, but without much success.
First some background. I was trying to run Exchange 2003 Standard Edition with OWA/OMA and EAS and SharePoint Services 2.0 on the same server, which was also a Domain Controller. Actually, it was the only server in the network.
Things started out great, I installed Exchange and performed the steps outlines in KB817379 (http://support.microsoft.com/kb/817379/), which I had to do to get OMA and EAS to work since I did not have a Front-End Exchange server. After testing all the Exchange services I proceeded with installing SharePoint Services. It installed without incident, but then the trouble started. OWA was not working, the same for OMA and EAS. WSS, however, was working. I started troubleshooting and soon found the article I linked to at the beginning of this post. Following the steps in it I was able to get OWA working, but not OMA and EAS. Every time I tried to sync a phone or access OMA I got an error in the event log that said HTTP 400 Bad request. Bad request means a malformed request was sent to the server.
Literally, for days, I search the net and finally had to put in a call to Microsoft PSS. The technician and I spent even more days looking at logfiles and traces of communication between server and clients. We were stomped. I was seriously beginning to contemplate reinstalling the server from scratch. But then we found something.
If you read article KB817379, in step 21 you see the value of the new VDir registry key you will create. Not that the article explicitly states that it should be /exchange-oma, with a forward slash. When we looked at the trace logs from Exchange we found this:
As you can see we had double forward slashes. This was the cause of the Bad Request message. An HTTP GET requestcontaining two slahes is obviously malformed. When I removed the slash from the VDir value in the registry and restarted IIS all services worked.
When this problem was resovled I installed the ActiveSync Mobile Administrator. That was also pretty hard to get working together with WSS, but I succeded.
Returning Search Statistics from Active Directory
When you search Active Directory you have the option of asking the server to return search statistics for your query. This is done by adding an LDAP control to your query. The control is 1.2.840.113556.1.4.970. I was using LDP to test this out on my test forest. The forest runs Windows Server 2003 DCs and I use the W2K3 version of the Active Directory Administration Tool; LDP. In that version of LDP it is very easy to add the required LDAP control to the search, you just select it from a drop-down box from the Search Controls dialog.
I specifically wanted to see the expanded queries that the server extrapolates when using ANR searches, or LDAP Display Names in objectCategory searches. But to my surprise, the server never returned any statistics. I always got the same standard output; the result of my search and nothing more. After a little investigation I found the following text on the MSDN site:
To retrieve all of the above information [search statistics], the account that issues the LDAP request should have debug privileges in its token.
I remembered having tested PWDUMP on that particular server. PWDUMP requires the debug privilege to work. I had removed that from the Administrators group to test something with PWDUMP. When I gave it back and logged off and on again i could successfully see the search statistics from the domain controller.
Nice!
Linked attributes in Active Directory
In Active Directory there is something called linked attributes. They exist in pairs, consisting of a forward-link and a back-link. The linked attribute pair member, of Group objects, and memberOf, of User or Groups is an example. In this particular case member is the forward-link and memberOf is the back-link. Back-links are always calculated automatically by the system whenever an attribute that is a forward-link is modified. If you change the member attribute of a group and add another object, the groups DN is automatically added to the memberOf attribute of the object you added.
I wanted to find out a little more about how this worked so I created a couple of scripts to do some testing. Specifically I wanted to see if I could write directly to a back-link attribute.
The first script tried to do that. It connected to an object in the directory and tried to write the DN of a group into the memberOf attribute. That failed with the error:
Code: 80072035
Error: The server is unwilling to process the request.
The next script connected to a group and added a user to it. As expected, that worked. I examined the user I added to the group in ADSI Edit and the back-link memberOf had been correctly computed. From that I can draw the conclusion that the computing of back-links is implemented in the DSA itself and not in the Admin tools (I was using a script, not ADUC, remember).
Next, I tried to edit the memberOf attribute of the user I had just added to the group directly in ADSI Edit. That provided the last piece of the puzzle and a conclusive answer to my question. Because that failed with the following error:
Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM).
So that was it. You cannot write to the back-link of a linked attribute pair. The back link is always automatically calculated and added by the system.
Also, the calculation and updating of a back-link attribute does not qualify as a change of the object. When I added a user to a group, only the group’s whenChanged attribute was updated. The user’s remained unchanged. That means that it is always the group object that is modified when you add a user to it. This seems obvious, but consider that you can also do this from the user’s properties on the Member Of tab. What you are actually doing is editing the group object, not the user.
Ain’t Active Directory fun!
Creating users with passwords that do not meet complexity requirements
I am currently reading John Craddock and Salley Storey’s book Active Directory Forestry. It is a very good read, and I can recommend it highly.
Anyway, I discovered something interesting. The book mentions some attributes of the RID Set object of Domain Controllers, specifically the rIDNextRID attribute of that object. rIDNextRID holds the value of the RID that will be given to the next object created on that domain controller. On my DC that value was 1130. Just for fun I created a new user and checked the value of rIDNextRID, only to discover that it had jumped two values insted of one, to 1132. This was a lone DC and no other objects had been created at the same time, so that was not the reason. I checked the SID of the newly created user and discovered that it had a RID of 1131. So which object had the 1130 RID?
I searched the forest for that SID and the search returned 0 objects. But then I asked LDP to return deleted objects as well, and then I got a match. The object with RID 1130 had been deleted at nearly exactly the same time that my test user had been created. The deleted object also had been named exactly the same as my test user. What had happened?
The answer was that when I created my test user I specified a password that did not meet the password requirements of my domain. You complete the create user wizard completely before you get that error from the directory service. So what happened was that the user had been created in the directory, but had been immediatley deleted by the system when it was found that the password did not meet the policy.
In the user interface I could simply click the back button and reenter a new password. That however triggered the creation of a new user, identical to the first one, but now with a compliant password.
I found this to be an interesting quirk and a nice insight into how the administative tools work.