Do you remember Exchange 5.5? Where messages that were delivered to Public Folders had the same message class (IPM.Note) as messages delivered to mailboxes? Ahhh – that was nice.

How about how Exchange 2000 changed it so that messages from the Internet to mail-enabled Public Folders defaulted to a message class of IPM.Post? I thought I'd blogged about this before, but apparently not. For those not aware of this, a quick overview is that Public Folder functionality changed with Exchange 2000. Messages sent internally to a mail-enabled public folder retained the message class of IPM.Note (standard message class), but any messages sent from an outside source were converted to a message class of IPM.Post (Message Post class), which causes some issues for clients attempting to reply to those messages, especially from OWA (there is no reply functionality). Outlook seems to handle it better (or at least Outlook 2007 does) and still gives you the ability to reply to a post within a public folder.

Microsoft released a KB article that addressed this issue (I think a lot of people complained about it…) in KB 817809, which allows you to basically set a registry value on your server, and change the behavior back to what many people would consider "normal" behavior, by modifying the PR_MESSAGE_CLASS field and changing it back to IPM.Note. This helps Outlook clients (and OWA clients for that matter) in that items now appear as messages instead of posts, but OWA still has a major problem in that you still can't reply or forward those items. The jist of it is that in order to reply or forward items in public folders in Exchange 2003, you need to have a Front-end server deployed. See http://support.microsoft.com/kb/822178 for details on the requirements to use different features in Exchange 2003.

Bottom line here is that if you require the functionality of being able to reply or forward messages (ipm.post or ipm.note) other than "Post reply to this folder", then you unfortunately have to deploy a Front-end server. At least one bit of good news is that with Exchange 2003, you can use Exchange 2003 Standard edition for that Front-end server, instead of having to use Enterprise edition (as Exchange 2000 Front-end servers required).

I first have to add a disclaimer that this cluster was a development system, so the data on it was of relatively little use. I also have to add that the configuration of this system in no way shape or form would mirror anything I would allow to be put into production.

Tip 1: Make sure that your Quorum drive (assuming it is not a local quorum) is on a RAID volume. This particular cluster uses iSCSI as its SAN. When the iSCSI server was initially set up (not by me), no RAID was used. I knew that it would eventually have to be changed, but due to the setup, I just kept pushing it off because, well, I didn't want to have to redo the entire cluster. Of course, one of the hard drives in the system failed. After letting the cluster sit for a while (offline, of course), I decided to tackle it and get it fixed. The first priority was getting the iSCSI server fixed. It was set up properly, with a RAID5 array for the hosts to use.

Tip 2: Make sure that you have the Windows (2003) Resource Kit downloaded and installed. There are some awesome utilities included in the Resource Kit. If you've worked with Windows long enough, you'd remember that there used to be actual Books and CD's for resource kit materials, and they weren't free! Thankfully, the Windows 2003 Resource Kit tools are freely downloadable. They came in VERY handy!

Armed with my knowledge, and my l337 searching skills, I began to search for how to fix my problem. In this case, I couldn't even start the cluster service. Attempting to do so generated an error indicating that the drive signature that was expected for the quorum couldn't be found. Duh. It wasn't coming back, either! Anyway, I came across several articles (Thanks to EventID.net) that helped me with this. The error I was seeing was event 1034 with a source of ClusSvc. Here are some of the resources I consulted.

http://technet2.microsoft.com/WindowsServer/en/Library/b410b421-78a5-4b3f-9247-e4f248f878fc1033.mspx?mfr=truehttp://technet2.microsoft.com/WindowsServer/en/Library/e2e5674c-0625-4aba-afee-0c7057f8ac2e1033.mspx?mfr=truehttp://technet2.microsoft.com/WindowsServer/en/library/3974d0c5-1c3f-4dce-921c-2859a8abd8ae1033.mspx?mfr=true

With the help of these articles, I was able to start up the cluster service with the /fixquorum switch (to do this, from a command prompt, use net start clussvc.exe /fixquorum), which allows the cluster service to be started. As anyone who works with clusters understands, until that cluster service is started, there really isn't much that can be done. With the cluster service started, I was then able to create a new physical disk resource, and then use the clusterrecovery tool, which is available in the aforementioned Windows 2003 Resource Kit utilities (Free download). The clusterrecovery tool allows you to replace a failed quorum drive by choosing another physical disk resource to replace it with. Once it does it's magic, it appends (lost) to the old Quorum resource and instructs you to delete it.

Of note is that once you are done with this maintenance, you need to restart the cluster service, otherwise it will continue running in the fixquorum state. Also of note here is that when replacing the quorum disk using clusterrecovery, ALL resources must be in an offline state (or failed, as it was in my case – hehe). Because of this, when you try to connect to the cluster, you must specify the physical node name as the cluster name, not the actual cluster virtual name (the Network Name resource is offline, so the cluster virtual name won't respond).

All done with this, I tested failing over to the other node to make sure that the resources all came online – they did. I then went about fixing the Exchange Virtual server, which was much easier. I'm pretty sure that I've blogged about that in the past, so I'll skip it this time, other than to say that the physical disk the Exchange virtual server was using had also failed (NEVER use RAID0 on a production server!), so I went through the process of creating a new physical disk resource for that, then deleting/re-creating the Exchange System Attendant Resource to fix the MS Search problems. I lost all the databases for that virtual server, but again, since it was a dev system, the data really didn't matter.

The Exchange 2007 Beta2 program is going to be a Public Beta. Everyone who signs up will be accepted into the program and given access to the media, so if you have any interest at all in Exchange 2007 and the changes that will be coming, make sure that you remember to sign up. Indications are that Beta2 will be available at the end of July.

http://www.microsoft.com/exchange/preview/default.mspx

In addition, you can now find all the most up-to-date technical documentation for Exchange 2007 online, and there are also other great resources such as sample Monad (PowerShell) scripts.

I suppose the bigger question is how much money they are losing on each laptop purchase, and will prices go up once they've garnered a larger market share?

Currently, Dell is running a special on their Inspiron 6400 line of laptops (expires tomorrow) for Small Businesses. Their 6400 with a DuoCore processor (1.6Ghz), 1GB ram, 80GB hard drive and DVD+/-RW (Dual layer even) is starting at $604 $699. I ask again, how can they do that without taking a loss on each sale? Or compromising quality? That's a pretty darn low price for a laptop, and though the Inspiron's are really geared more towards home users, I like them and like the way they look. They are a little bigger and heavier than their Latitude counterparts, but Dell has been touting these as desktop replacement systems, so probably the thinking is that you won't have to lug it around as much. Even if you do, at ~6lbs, it really isn't that bad.

My Father-in-law recently experienced a problem with his Inspiron 6000 where the network card was having issues. That escalated into more severe problems that seemed to point to a faulty mainboard. It's finally getting fixed, but it does sort of highlight the above question, though I know several other people that own Inspiron 6000's (my mother being one), and haven't heard of any widespread issues with them.

One thing to note is that the default warranty that comes with these laptops is a 1 year economy on-site warranty, so perhaps that is part of why the low cost. However, I'm a firm believer that if there are going to be serious problems, they will usually crop up fairly early.

Bottom line here is that if you are in the market for a mid-level laptop, it looks like Dell wants your business pretty bad.

Update: The price has been changed and is now $699, not $604. Possibly it was a pricing mistake.

Here's another post in my series about Windows Mobile devices.  My last post talked about frustrations with the Q.  Those issues never got fully resolved, but I'm not as concerned about them, because I don't own the device, and I haven't been asked to get it working.

I did find some interesting information, though.  I feel rather fortunate that my device is completely unlocked, so I can muck with all the settings I want.  For those that don't have unlocked devices, there may be *some* hope.

MSDN contains information on the Default Security Policy settings for both Windows Mobile Pocket PC's and Windows Mobile-based Smartphones.  Check them out!  Of interest is the section referring to the Grant Manager settings.  I had seen several comments on the Windows Mobile team blog that referred to changing the registry key value in HKLM\Security\Policies\Policies\00001017 from the default of 128 to 144 and that this would aid in being able to install certificates, but didn't quite understand why that would make a difference until I read the MSDN documentation.  The MSDN article indicates that the registry key 00001017 is the setting for the Grant Manager Policy, which basically defines which roles are granted system administrative authority.  To understand these settings, let's look first at what the different roles are (there are actually a few more which are listed in the link below, but I don't think they are particularly relevant):

The thing to understand about registry settings such as these is that they can be used singularly, or in combination. When you look at the value of the key, it represents all settings that are enabled. By default, on non-phone based devices (Pocket PC only), the default setting (outlined in the MSDN article) is actually set to Decimal 16 (Hex of 0x000010), which equates to SECROLE_USER_AUTH. On phone-based devices (Pocket PC Phone edition and Smartphones), however, it defaults to Decimal 128 (Hex 0x000080), which is SECROLE_OPERATOR_TPS. By changing the value to Decimal 144 (Hex 0x000090), what you are actually doing is enabling both SECROLE_OPERATOR_TPS and SECROLE_USER_AUTH (128+16 = 144). In the same section of the MSDN site, another page describes the various security roles.

The only bit of advice I feel compelled to share here is to make sure that you document any settings when you make changes. There is nothing worse than knowing you changed something, but forgetting where it was you made the change, and what the default value was, especially when it is causing problems.

I now understand what the comments were talking about in my earlier blog about being continually prompted for the password when attempting to get Exchange ActiveSync up and working.

I tried to get a Motorola Q working via Exchange ActiveSync today, and could not get it working. I tried everything I had done with my device, including adding the registry key (remember, we use a wildcard cert), and attempting to install our cert. Verizon has apparently locked down being able to just add certs the normal way with Windows Mobile 5 (BOOOOOO!!!), and requires you to use the old spaddcert.exe tool, which apparently won't let you add just any cert. When I tried adding ours, it kept telling me that it wasn't a valid root certificate.

Anyways, modifying the registry key (HKEY_CURRENT_USER\Software\Microsoft\ActiveSync\Partners\Partnership for Exchange server) and adding the key of secure=0 got rid of the invalid certificate prompt, so perhaps the certificate issue has been resolved. Even so, I'm not quite sure how to get past the password prompt.

In summary, I've got a few issues with what Verizon has done to the Q.

1. Why on earth does the Q not ship with MSFP/AKU 2.0? That is INSANE! We're talking about an update that was released to manufacturers in November of LAST YEAR, for goodness sakes. Verizon needs to get off it's rear end and get an MSFP/AKU 2.0 update pushed out.
   
2. What is really the rationale behind locking down devices, such as preventing the installation of certain certificates? I can completely understand a carrier wanting to lock down a device so that it will only work with their network, but I don't understand this nonsense of locking down other portions of the device so that it makes life harder for IT folks.
   

I will, however, give kudos to Motorola. The form factor on the Q is pretty nice, and even with the extended battery installed, it still seems smaller than any Blackberry I've seen. The screen (even though it is only 320x240) appears bright and sharp. The screen, however, isn't a touchscreen, so don't expect to use it as such (no stylus included).

Are you experiencing similar issues with your Q, or another Windows Mobile 5 device? Have you gotten the dreaded continual password prompt? If so, what did you do to get around it?

If your Windows Mobile device isn't automatically syncing with Exchange, make sure you check the Date and Time on your device. If it isn't correct, then you won't be getting updates.

I recently was without my Windows Mobile device for 3 weeks, and when I got it back, it was *completely* out of juice. Luckily, with Windows Mobile 5.0, I didn't have to worry about losing any data (Yay!). Once I charged my device, I did a sync to get everything working, and it pulled in a bunch of e-mail, so I figured everything was ok. Then I noticed that it wasn't receiving updates. I'd see new messages on my Outlook client, then I'd see that they weren't there on my Jasjar. I thought that was a bit odd, because with Direct Push, I'd usually end up seeing the messages on my device before they would show up in Outlook (cached mode). Performing a manual sync on the device would pull over all mail, but nothing was getting synced automatically. I was hoping that I wouldn't have to delete and re-create the Exchange server partnership, but was almost ready to do just that.

What finally caught my attention was looking at the day that was displayed on the home screen. It said it was Sunday, when in fact it was Monday. Turns out it was a whole year off. Anyways, once the time issue was corrected, Direct Push started working again just like normal. So this is a note to remind you that if you aren't getting automatic syncs, check your date and time.

Thanks again to Jeffrey Snover, I've finally gotten the history to be preserved between MSH sessions. It took a little tweaking in order to get it right (for me), but here are the steps I followed.

1. Create a profile.msh file. Within the Command Shell, if you run $profile, it will tell you where your profile is. At first, I was struggling with this part because I haven't been doing a lot of work with Powershell. A few web searches yielded the information I needed, which indicated that within my 'My Documents' folder, I needed to create a directory named 'msh', and then create a file within that msh directory called profile.msh. Of note here is that (at least on my system) you can't directly edit .msh files. So each time I wanted to edit the contents, I had to first rename it to a .txt extension. No biggie.
   
2. Add the code to the profile.msh file. I had to make some changes to the code that Jeffrey posted. I'm not sure if this was due to me using the Exchange Management Shell instead of Windows Powershell (though they really are the same thing), but I'll first post the initial code that Jeffrey posted, and then show you what changes I had to make.
   

OK – the first problem I ran into was that with the above code, each time I launched the Exchange Management Shell, it would throw an error stating that 1KB was an invalid integer. Once I finally got it through my thick head that I indeed needed to supply an actual integer, that was easy enough to fix :-)

The second problem I ran into was the first if statement. It was complaining that it couldn't find a parameter that matches the parameter '-PathType'. I'm not sure what that was all about (it appears to be having a problem creating the 'Powershell' directory), but I wanted to get this working, so I removed those lines. I ended up with the following code that works. All you have to do is type 'Bye' instead of Exit (this also means you can't click the 'X' to close the Shell window), and your history will be preserved. If you'd like to use this, feel free. If you'd rather, you can also change the export function to export-clixml, which will export it to an XML file instead of a CSV file. You would then also need to change the import function to import-clixml. The below code will save the history.csv to the root of your user profile.

$MaximumHistoryCount = 10000
function bye
{ Get-History -Count $MaximumHistoryCount Export-CSV ~\history.csv
exit
}

if (Test-path ~\History.csv)
{ Import-CSV ~\History.csv Add-History
}

update: had to edit this post as the code didn't come across right from Word. It should be good now.

Yesterday, I posted about the History command, or more accurately, how I felt it was a bit lacking in how it functioned.

Since then, I've received 2 suggestions for enhancing the history (or get-history) command.

The first suggestion came from Ross Smith IV on the Exchange team. He indicated that you can record your entire shell session simply by entering the command

Start-transcript

This will literally record every action that takes place within your command shell. The only downside (if there is one) is that it is very verbose, so it *really* records everything. The information is recorded to a text file in your My Documents folder by default. Recording ends automatically when the MSH session is exited, or by typing Stop-transcript.

The second suggestion comes from Jeffrey Snover, who is part of the Windows Powershell Team. He left a comment on the original post, but I thought I'd include it here as well. He blogged about a way to preserve history across sessions.http://blogs.msdn.com/powershell/archive/2006/07/01/653194.aspx

Thanks for both of these suggestions. While they are quite different, both are great options.