Visual C# Express 2010

It seems like a long time since I studied to be a programmer. In fact it was back in 1999 that I completed my Dip BC in the programming stream at CPIT. A stint of Access development over some holidays convinced me I was not cut out for that line, and when I returned to CPIT later on I did more of the support stream courses. My current work is in the support stream with a little bit of programming thrown in. With my previous experience and having a copy of Delphi 5 Desktop I have written the occasional small console app in order to run in logon scripts and the like.

But of course as time rolls on, Delphi 5 becomes obsolete. Now, with the free Express editions of Visual Studio available, it has long seemed that a switch to one of these .NET-based development tools would suffice, but even though I did a VB course way back in 1997 or something, .NET is all different and new and unfamiliar. My current interest mainly comes from our switch to Live@Edu, and tinkering to see if it is possible to knock up a simple GUI to edit custom mailbox attributes that aren’t exposed in the Outlook Live Control Panel. When I first went looking for the Visual Studio Express Edition downloads I was kind of torn between VB.NET and VC#, it would be “easy” to go with VB, but I never liked programming in BASIC, and even though I disliked C, especially case sensitivity, most of the code examples you will see out there now are for VC# (or VC++) because VB isn’t really taken seriously as a development environment. Anyway I did C programming as well so it is not all new (I’ve done heaps of different languages: Pascal, Delphi, FORTRAN, COBOL, Jade, Logo, C, Java, BASIC, assembler, etc). The learning curve has not been that sharp for VC#.

Whether I can turn a hacked together console application made up of various code snippets put together into something worthwhile, that can change these custom attributes easily (we would use them to populate dynamic distribution groups) remains to be seen. There is some other potential in VC# Express’s database capability, particularly being able to connect to a Access database. However its lack of reporting functions means you can’t spit out any output. So really for our purposes its main functions would be non databasey. Still, if we needed more, we could buy an AE edition of Standard or Pro, which I presume would come with Crystal Reports. If I ever need to do some custom reporting that is beyond what we can do in Access then that is a path I might look at going down in the future.

Anyway the IDE and development environment in general is very, very good, with all the syntax highlighting, code completion, immediate error checking and what have you. This really promises to be fun!

Moving right along…

It was just a year ago that I blogged about our progress in the direction of migrating to Exchange Server 2007. One year on, we have just finished uninstalling that server after migrating everyone for a second time, to Live@Edu. What changed our great plan to run our own in-house Exchange server?

1. Exchange 2007 is a very complex system that requires a lot of technical resources to set up and maintain. We don’t have those resources in-house, and contracting people to bring them in is expensive.
2. The complexity of Exchange will continue to increase with subsequent releases. 2007 increased markedly over 2003. Maybe if we had 2003 my view of it would have been different.
3. Exchange proved temperamental to get running on our configuration, apparently because IPv6 was running by default on Windows Server 2008.
4. We had only 40 mailboxes max running on the Exchange server which is a very small usage considering its capabilities
5. The server it runs on can only have 8 GB max RAM due to Intel’s designed architectural limitation of the particular chipset (dumb, huh!). Exchange for even this small number of mailboxes uses a lot of that memory.
6. We have not had time to set up a regular backup of the Exchange database.
7. Two of our other servers will need to be replaced at the end of 2010. We decided the best use of the hardware resources of the server running Exchange is to virtualise these physical servers rather than replace them. To do that Exchange has to be taken off that server because it uses too much resources, considering the server’s memory can’t be increased.

Now, why did we get Exchange in the first place?

1. Exchange provides a compelling server based solution which leverages all of the rich functionality of Microsoft Outlook. If you are like me, someone who likes to use their Contacts, Calendars and Tasks, then the advantages of Exchange above just a mail server are very strong.
2. We had to move from a Linux platform to a Windows platform and Exchange is an obvious fit with Windows.
3. Email hosting with our local ISP would have (and probably still does) cost around $1500 per year which means that the cost of a $4500 Exchange server would pay for itself in 3 years.

Hence we went for the Exchange solution which we started to implement at the beginning of 2009. Just as we were starting to do this, the Live@Edu hosting solution was starting to become available. I chose to create a Live@Edu solution for our hundreds of student email accounts. We carried on with Exchange and got all the staff onto it at the end of Term 2 (mid year). The honeymoon did not last very long and within weeks I was testing Outlook Live on a subdomain. Once it became clear that this would be a viable solution it was put into our plan for 2010 and has now been implemented. So the staff switched mail solutions twice in three terms. And today I uninstalled Exchange from the server so there is no more conflict with the Live@Edu hosted solution.

The other items I wrote about in that previous post were Terminal Server and ISA Server. We have instances of both of these in operation at present and will be continuing with them. ISA was a bit of work to get going but now it’s fine. TS was relatively straightforward but had to be put onto its own virtual server (Hyper-V) for security reasons. The next step is to move the TS Gateway off the Hyper-V server itself (the former Exchange server) onto the TS virtual server. Once that is completed I can get on with my task of turning the Exchange server into a dedicated Hyper-V host server which will eventually have a DC, TS and ISA running in separate client server instances. Our other Windows Server 2008 box is also going to be a dedicated Hyper-V host with a DC and file/print as two separate client instances. In addition there is the question of a Vspace server for NComputing thin clients, which I haven’t worked out yet, and which in the short term runs on the FP server although it is not ideal to have that.

Windows 7 Windows XP Mode, Live@Edu Customisation

One of the useful features of Windows 7 is XP Mode, but hitherto it was only available for computers which had hardware assisted virtualisation. This meant I couldn’t use it because even though this PC is only 2 years old, the Intel CPU is a model that doesn’t have vT support. MS has recently changed the implementation of this product so that it doesn’t mandate a vT capable CPU. This means I can install our SMS application onto my Windows 7 desktop (because the vendor hasn’t certified the application for Windows 7).

Another interesting thing I am looking at is having a custom control panel for our Live@Edu mailboxes. Obviously you can use the Outlook Live Control Panel to change the detail settings of mailboxes. However if you want to change the CustomAttributeX attributes of the mailbox you have to use the Powershell to set them, and of course this is not a GUI process. Other issues are:

• you can’t rename the custom attributes
• you can’t create your own attributes with useful names
• you need some way to validate data input depending on what is to go into each attribute

Because of this I have started to play with Visual C# Express to see if I can do a form based app that can call Powershell to get and set the custom attributes. It would be able (I hope) to let me put a useful label on the screen for what each field is being used for, and validate data etc. VC#X will let me call Powershell from within the app so I could connect to a powershell remote session on the Exchange Live server hopefully.

The most useful thing I expect to be able to do with these custom attributes is to be able to set up dynamic distribution groups that run custom queries across them to generate the recipient list. If you have a situation where any user can end up being a member of multiple groups, it is probably a lot simpler to use these custom attributes and change them for each user than having to edit the multiple groups in turn.

I have made a slow start on getting my home PC rebuild project under way, buying and fitting a nice new Enermax ATX 2.1 power supply. It now requires the motherboard, CPU, RAM and a new 250 GB HDD to be purchased.

Also recently I am looking at desktop remote admin again, and trying out a few different programs. So far the best all round is a freebie called RD Tabs which is similar in principal to the old Remote Desktops MMC that first made an appearance in XP and reappeared in Windows 7. The idea is that you can open multiple remote desktop sessions simultaneously to administer desktop computers easily (for example, a suite). Since we only have one suite it isn’t too big a deal as long as you can also turn them on remotely using WOL. There has been a lot of fun in discovering that some computers aren’t responding to WOL commands and others are going to sleep and not waking again. I hope the next lot of computers we have in there are much better with WOL. Anyway this RD Tabs is a huge improvement over the usability of the MMC that MS provides, because you can change the settings for each tab individually and save them etc. And it is also free. So Avian Waves’ RD Tabs is definitely worth looking into for this kind of application.

Migrating from Exchange 2007 to Live@Edu -3-

Well, our migration is almost complete. We are still working on a few small things here and there. There has been one very significant issue that a number of our users have experienced and that has been that their addresses which they used in the old domain have been changed into funny addresses that look like an LDAP path (starting with /O= and all the other parts broken down). These are the addresses that we are having trouble with.

It turns out that these addresses are all stored in Outlook’s NK2 file (address autocomplete) and a possible solution is to edit the file and remove the particular entries in question. A tool called Nk2Edit.exe can do this for you. The type of entry that I am guessing will cause the problems is the EX type entry which (as you can see from the sample screen shot on that page) contains a string of data in that LDAP format.

I suppose the big question is how these addresses get changed in Outlook’s NK2 file. It must happen when the user’s account is taken out of the old Exchange server and put into the new one. There doesn’t seem to be any logical reason why this should occur.

As things have rolled along this week, I have spent a lot of time using Exchange Powershell to set miscellaneous options on various user identities. The current edition of OLCP is not yet as powerful as the Exchange Management Console that you get for a local Exchange server. So some things will still need to be configured with Powershell. I have solved more than a few technical problems this week with Powershell, and extended my knowledge of the operations that it can do in more than a few ways.

Migrating from Exchange 2007 to Live@Edu - 2

Last time I posted about some of the early steps of getting mailboxes across to Live@Edu. As of this moment I have not had a response to my query raised with Outlook Live as to the Import-Mailbox functionality. We have migrated all mailboxes manually by setting up Outlook to connect to the account and then using the Import and Export command on the File menu to import the PST file that was exported as described in the previous post. Once the import is completed there is an indeterminate period of waiting for Outlook to fully synchronise the offline cache with the remote server. Generally for some users this would take hours and could be left running overnight.

I am also experimenting with calendar sharing. In our testing we had determined that calendar changes were not being synchronised back to the server in “real time”. This would make it hard to share a calendar practically. The Outlook 2007 Group Policy template allows the various settings to be configured. I have set all these to 60 seconds. The default supposedly is 5-60 seconds but this might only apply for a server in the premises and be overridden for a remote server.

One thing that will become apparent when you set up distribution groups for your domain is that there is not yet a means of generating and maintaining dynamic distribution groups in Outlook Web App or the Outlook Live Control Panel. This is one of a number of areas where you will have to learn Exchange PowerShell commands. It will be a few more releases before the OLCP will approach the Exchange Management Console in functionality. When you create a dynamic distribution group you will need to specify an OU for your domain, the easiest way to get one is to query some other distribution group or user account to see the OU path that Exchange Labs has defined for your domain. DDGs will show up instantly in the GAL but of course, not in OLCP. Also while Outlook Web App can show you the membership of static groups in the GAL, it can’t give any information on how a DDG is defined.

An important consideration in setting up any new domain to be managed is the assignation of administrator roles. In particular, Exchange 2010 has the RBAC system implemented for managing these roles. One of these roles is Discovery Management, which gives the assigned user the power to search mailboxes. Obviously this is one role you’d want to think very carefully about before implementing.

I am also testing the difference in functionality between Outlook 2007 and Outlook 2010, it looks like Outlook 2010 will let the user save their Outlook Live connection password and of course there are many interface improvements in 2010 which is where a great deal of work has gone, but that is out of the scope of this article at present.

Migrating from Exchange 2007 to Live@Edu

If you have a registered Internet domain name and you want to provide email addresses to your users based on that domain name, you have basically two options:

• Provide an on-premises mail service and infrastructure
• Utilise externally provisioned (hosted) mail services

Historically, the second option has only been viable with a fairly small number of email addresses. Once you get above, say, 40 or so addresses, the first option could become more economic. This was the reason that we chose in our school to implement the first option. In point of fact, we originally had some 500 email addresses on our first site mail server. The server had to be replaced and Exchange 2007 was the chosen platform. The actual implementation of our Exchange 2007 solution, as it turned out, began at about the same time as we first heard about the Live@Edu service. We put the hundreds of student email addresses onto Live@Edu Hotmail, using a subdomain, but kept our primary domain and staff email addresses on our site mail server, transferred to Exchange 2007. Over the 12 months that we have used Exchange 2007, we compared it with the services being offered free to schools on Outlook Live, and made the decision to transfer our 40 staff email addresses to Outlook Live on Live@Edu. Because the Live@Edu service is hosted free of charge, it is significantly superior to an on-premises mail server and the cost advantage blows away the traditional ISP based services which were quoted to us at $3 per user per month (around $1500 per year) and which generally offer a puny 10 or 100 MB per mailbox compared to the 10 GB that Microsoft is providing.

Well it’s now April 2010 and a few days ago I started to migrate our users off our Exchange server. The first step is, we need to be able to move their mailbox contents. In Live@Edu help, you are given a couple of suggestions, which are basically setting up an automatic migration using POP or IMAP, or going to each user’s computer and exporting their stuff from Outlook to a PST file. The auto migration option using POP/IMAP can only migrate mail, so it is not useful for migrating from Exchange. If you are using Exchange and have a computer running 32 bit Windows and Outlook 2007 with the Exchange Management Tools installed (2007 SP1), you can use the new Export-Mailbox cmdlet in the Exchange Management Powershell to export a user mailbox to a PST file without having to go to a user’s computer to do it. In order to be able to do this, you will need to grant yourself Full Access permissions to the user’s mailbox first of all. This is pretty simple to do: either use the Exchange Management Console, or in the Shell enter this command:

Add-MailboxPermission -User <your name> -AccessRights FullAccess -Identity <mailboxname>

The actual command to do the export looks like this:

Export-Mailbox  -PSTFolderPath <Path_Of_PST_Folder> -Identity <MailboxIdParameter>

Path_of_PST_Folder is a folder on the computer where you are running the export. It will create a PST file in this folder which is automatically named based on the mailbox name. If you have a smallish number of mailboxes, just run each command manually for all of your users in turn. When you run the Export-Mailbox cmdlet, you are first asked to confirm the export: the response I used is A (all). Then the export will display a progress bar and status messages in the shell window as it proceeds. Finally it will provide a status report and it also files copies of the status reports in a folder in the Exchange Management Tools installation path. If you have a larger number of mailboxes and advanced knowledge of Powershell, you could further automate this process by piping in a list of users as input to these two commands. I figured that by the time I had worked out how to do this, I would have already been able to complete the manual steps so the manual process was how I did it.

After we have exported all our mailboxes, we need to import them into Exchange Live. There are two ways we could do this, only one of which is described to any degree in the Live@Edu documentation. Basically you can either use Outlook 2007 to import the PST directly, or it is possible that you could use Windows Powershell to connect to Live@Edu allowing the Import-Mailbox cmdlet to be run against the remote Exchange server. The latter option, not being configured by default in Outlook Live, would require many steps to set up and probably, going by my initial explorations, technical support from the Live@Edu helpdesk. As I only have a small number of mailboxes to import, I have gone for the first option. You can implement this option on any computer running Outlook 2007, provided you know each user’s Windows Live ID and password. All you need to do is to set up the account in Outlook in the usual way, and then use Import and Export on the File menu in Outlook to import the PST file for that user that was created from the Export-Mailbox cmdlet in Exchange Powershell.

At this point in time it is possible that you will find that your Autodiscover settings in your on site mail server are interfering with and blocking the Autodiscover DNS settings that you have configured for Outlook Live. When I initially tested this at our school, I was onsite and consequently I was able to shut down the Exchange server in order to stop the interference. However, this server is also running the Terminal Services Gateway and so I wouldn’t be able to log in remotely while it is shut down. So I tried out a few things to disable the Exchange server’s autodiscover. The first things I tried were shutting down Exchange itself by stopping all the services whose names start with “Microsoft Exchange” on the server. However Autodiscover kept running as it is actually provided by IIS. When I worked that out, I went to the IIS management console and stopped “MsExchangeAutoDiscoverAppPool” and all the other application pools with names starting with “MsExchange”. Finally, this was successful in turning off the Autodiscover, and setting up new accounts in domain connected computers could proceed.

If you look this up on the net, you will find a recommended solution from Microsoft here, this is based on setting some registry keys to stop Outlook from using the site autodiscover functionality and the registry keys have to be changed on the client computer where Outlook is running. This could be a better option if you have to keep your onsite Exchange server fully functional during or after the migration. As it is, I have the option of being able to shut down Exchange so that I don’t need to bother with client configuration.

Once you have the account set up in Outlook, you can import the PST file directly to the user’s account. The trap for unwary players here is that Outlook doesn’t immediately upload the imported content to the Outlook Live server. Instead it puts it into the offline cache and synchronises it over a period of time. If you have to migrate a number of users in this way, you need to make sure the offline cache is fully synchronised before you remove their account from the computer where you are running the imports (you would do this in order to set up the next user’s account for importing). The way to do this is to click Send and Receive and watch the progress dialog, this will show that the synchronisation task is taking a certain number of minutes, which obviously varies depending on the size of their PST file and the speed of your broadband connection. It can be a slow process this way. That is why I would like Live@Edu to facilitate people being able to import their mailboxes in Powershell because it can be automated. At the moment, importing a large mailbox through Outlook can take hours to complete, the speed of broadband being the limiting issue. The only real workaround for this at the moment is to do it on each user’s own computer and therefore because the account is set up permanently on that computer, you don’t need to wait for the synchronisation to be completed.

So as of right now, I am slowly migrating people over the next few days, and we will have to see how things go from here.