July 2005 - Posts
If you are a sometime reader of this blog you may remember a recent post concerning Outlook Web Access not working correctly for non-administrative users. Feeling somewhat at a loose end on Friday evening I decided to try resolving this issue and, after spending a large chunk of the weekend on it, I've now got Outlook Web Access and Exchange ActiveSync working correctly from inside our network.
The problem with non-administrators not being able to access Outlook Web Access (OWA) turned out to be a simple one. Our internal domain has the name internal.domain.com whereas our external domain, from which email's are sent/received, has the name domain.com. When we installed Exchange Server it did the sensible thing and configured the SMTP domain as internal.domain.com and user's primary SMTP addresses as user@internal.domain.com. However this was not what we wanted, and not being very knowledgeable in Exchange, we just used Active Directory to change the user's email address to user@domain.com. This allowed us to send/receive email correctly but this is what was preventing users from accessing OWA. Basically when logging in through OWA, infromation is retrieved from AD and matched against known recipients in Exchange; because user's primary AD email addresses (user@domain.com) did not match the Exchange SMTP domain (internal.domain.com) it would not allow the user access.
In my naiviety I did not know about recipient policies in Exchange. The solution to my problem was simple; modify the default recipient policy so that default user addresses are of the form user@domain.com. This sets the primary addresses in AD as desired and hey presto - everything now matches when users connect via OWA and access to email is allowed. So why did the Administrator account work all along? Because that was the only account for which I hadn't modified the primary email address information in AD so everything worked as it should have done.
Having got OWA working fairly quickly I also wanted to get Exchange ActiveSync going too. This proved to be more problematic. I set an SSL certificate on the server for the Exchange virtual directory, set up a Pocket PC and described in the documentation and promptly got an HTTP_403 error. This appears to be a well known issue and the solution is to follow method 2 in this KB article (KB817379: Exchange ActiveSync and Outlook Mobile Access errors occur when SSL or forms-based authentication is required for Exchange Server 2003) to set up an alternative Exchange virtual directory which does not use SSL as is accessible only from the server itself. This changed the situation as I now got an HTTP_500 error everytime I tried to sync with the server. Again this was caused by a mismatch between SMTP addresses; perhaps this was because I (briefly) successfully set up Exchange ActiveSync on the PocketPC when the SMTP addresses where stil set as users@internal.domain.com and this info was cached in the device leading to a subsequent mismatch when I changed the addresses to the proper external address. Anyway, the solution was found in another KB article (KB886346: You receive an HTTP_500 error message when you synchronize your mobile device with Microsoft Exchange Server 2003). The solution was to add an SMTPProxy registry key for internal.domain.com, then to add a secondary email address of the form user@internal.domain.com to each user in AD. This immediately solved the problem and allowed the PocketPC to sync correctly with the server and it has been working flawlessly ever since. Setting the SMTPProxy to any other (valid) SMTP domain known ot the Exchange server did not work though.
Anyway, I got it going which pleases me greatly. All I need to do now is get OWA and Exchange ActiveSync working properly through our firewall and we'll have email access on the move from wherever we happen to be. Isn't the modern information age wonderful!!
------
David
del.ico.us | 
Digg It | 
Technorati | 
StumbleUpon | 
Furl | 
reddit
I've been working on a project recently using Microsoft's Enterprise Library, and in particular the Data Access Application Block(DAAB). The project is a .NET 2.0 project and I've been using Visual Studio 2005. As I'm a big fan of test driven development I thought I'd play around with the unit testing capabilities of VS 2005 for unit testing this project.
The Enterprise Library places some information in the app.config file which it loads at runtime. It also places additional configuration files (in this case dataconfiguration.config for the DAAB) in the application and reads data from these at runtime too. Having created a test project in VS 2005 I couldn't for the life of me get the Enterprise Library to pick up the information it required from the app.config of my test project. VS 2005 unit test projects are meant to pick up application configuration information from either app.config or <classlibrary>dll.config as nUnit does. Having done a bit of Googling it would appear that there is a bug in VS 2005 Beta 2 which means that it can only currently pick up application configuration from <classlibrary>dll.config. Renaming my app.config to <classlibrary>dll.config and setting its Copy to Output property to Copy Always solved the problem and allowed the Enterprise Library to pick up its configuration data.
But... having solved that problem, Enterprise Library could not pick up the additional configuration (dataconfiguration.config) file it requires. This too was added to the test project with its Copy to Output property set to Copy Always but this did not solve the problem as the file was never copied to the temporary directory where VS executes the tests (another bug). In fact, any file other than <classlibrary>dll.config does not seem to get copy to the temporary test directory even if it is set to Copy Always. I eventually figured out that what you need to do is create a Test Run Configuration (right-click Solution Items then select New Item->Test Run Configuration) and use the deployment tab of the Test Run Configuration wizard to specify which additional files should be copied to the test directory. Finally, use the Test->Select Active Test Run Configuration... menu to set this test run configuration as the active one. Now when you run any test from the Test View window this configuration is used by default and the additional files specified will be copied to the test directory.
My unit test project can now pick up all configuration required by the Enterprise Library so now I can get back to doing some actual development. However I've lost a good couple of hours trying to figure this out - there is definitely a need for a Unit Testing How To in the VS 2005 MSDN documentation methinks. Hope this little post helps saves someone else a bit of time.
-------
David (with a few less hairs than I had before...)
del.ico.us | Digg It | Technorati | StumbleUpon | Furl | reddit
If you've tried installing and configuring Visual Studio Team Foundation server yet, you'll know that it's a fantastic example of a software product that is easy for the end user to install and configure - not!!! There also seems to be a singular lack of any real documentation at this point though there are plenty of posts on the Web regarding installation failures, etc. I've spent two days this week trying to get Team Foundation Beta 2 up and running on one of our servers so we can evaluate it. If you're thinking of setting it up then I'd offer the following tips:
- Sounds obvious, but... read the Installation Guide that comes with Team Foundation server and follow it to the letter. Slight deviations from it seem to result in failed installs and the dreaded 32000 error
- Use the bits that come with beta 2 when installing Team Foundation server. I can tell you from 6 hours of bitter experience (and from this post) that it doesn't seem to want to install on the SQL Server 2005 June CTP (T-SQL scripts failures probably due to changes in T-SQL changes in the June CTP), but works fine on the April CTP that comes with the beta
- When you finished installing, don't forget to add account(s) to the Namespace administrators group as described in the installation guide
- Set up the authentication properly for creating new projects. This bit is really unclear and caused me much head scratching when trying to create some new projects. If you follow the steps in this post it does work
- If you're trying to get Team Foundation to perform builds on the server for you then don't forget to install the Team Build component as described in here and here. For some reason best known to the guys at MS, the Team Build doesn't get automatically installed by the main install and you have to install it manually once you've got Team Foundation server up and running.
Having finally got Team Foundation working properly I created a project for an ASP .NET application we're working on at the minute and tried to build it. Guess what? It failed because the ASP .NET compiler couldn't find the source files in that right place. This is due to the solution file containing absolute paths to files the development machine and they need to be modified as described here. Having modified the solution file, the ASP .NET application now builds perfectly on the Team Foundation server and seems to (mostly) still build correctly on the development box. I haven't tried checking the project out to a different location or on another box to see if it still builds correctly there - that's my next job!
If you're looking for information on setting up and using Team Foundation server then the MSDN Team System forum is a great place to start, though Google will probably become your best friend too!
del.ico.us | Digg It | Technorati | StumbleUpon | Furl | reddit