Category Archives: Windows Mobile

My journey from Windows CE to Android

Posted on by — No Comments ↓

After over 14 years using some kind of Microsoft-powered mobile device, I recently got a Google Nexus 4.  I thought I would look back at the devices I have used over the years.  Most have long been recycled, but a few of them are in a drawer (or perhaps even the garage).

Google Nexus 4 (LG E960)
Released: November, 2012		 Google Nexus 4
AT&T Tilt2 (HTC Rhodium)
Released: October, 2009		 AT&T Tilt 2
Samsung BlackJack (Samsung SGH-i607)
Released: November, 2006		 Samsung BlackJack
Cingular 2125 (HTC Faraday)
Released: March, 2006		 Cingular 2125
Cingular 8125 (HTC Wizard)
Released: January, 2006		 Cingular 8125
Sprint PPC-6700 (HTC Apache)
Released: October, 2005		 Sprint-PPC6700
Siemens SX66 (HTC Blue Angel)
Released: December, 2004		 Siemens SX66
Audiovox SMT-5600 (HTC Typhoon)
Releases: November, 2004		 Audiovox SMT5600
Audiovox PPC-4100
Released: June, 2004		 Audiovox PPC-4100
Hitachi SH-G1000
Released: July, 2003		 Hitachi G1000
Siemens SX56 (HTC Wallaby)
Released: October, 2002		 Siemens SX56
Casio Cassiopeia E-100
Released: May, 1999		 Casio E100
Philips Nino 300
Released: September, 1998		 Philips Nino

Use the Exchange Management Shell or LDAP to get a list of quarantined mobile devices

Posted on by — No Comments ↓

You can use Exchange Control Panel to view the list of Exchange ActiveSync devices that are in a quarantined state.  I wanted to be able to get this list without using ECP, but I didn’t know where this information is stored: Exchange or AD?  Long story short, it is stored in AD.  Every Exchange ActiveSync partnership exists as an AD object (whose class is msExchActiveSyncDevice) located as a child object of the user object whose mailbox has the partnership.  The access state of the device is stored as an integer in the msExchDeviceAccessState attribute of the object.

To use EMS to get the list, run this command:

If you want to use LDAP to get the list, this is the corresponding search filter:

(&(objectclass=msexchactivesyncdevice)(msexchdeviceaccessstate=3))

The device access state values are 1 for allowed, 2 for blocked, 3 for quarantined.

The correct way to restrict users to specific devices with Exchange ActiveSync

Posted on by — No Comments ↓

One way to control access to a mailbox with Exchange ActiveSync is to restrict a user to a specific device ID (or more than one), as described in this TechNet help page. The prerequisite listed on the page is only that the user be enabled for EAS. You will find, however, that if you list one or more device IDs in the ActiveSyncAllowedDevicesIDs property and attempt to sync with a device that is not in the list, it will still be able to.

The reason for this is not explained clearly in Microsoft documentation, but can be inferred by this good post on the Exchange blog. It details the flow logic when a device is accessing a mailbox and the order in which permissive and preventive access is handled. This image from the post sums up the flow:

When a device attempts to sync with a mailbox, the Allow/Block list on the user object is checked first, followed by any device access rules defined at the org level, and then the global access rule (the decision point labeled as Anything Unknown).  The default configuration at the org level is a permissive organization, where any device not explicitly blocked at the user level or does not match any device access rule is allowed.

The important distinction, however, is that specifying an allowed device ID at the user level is not exclusive, while specifying a blocked device ID is [effectively] exclusive.  This means that the access logic doesn’t stop at the user level when an allowed device ID is specified, though it does when a blocked device ID is specified.  Therefore, in a default permissive organization, specifying an allowed device ID for a user does not restrict the user to only that device.  In order to restrict a user to the device ID(s) specified on the user object, it is also necessary to define a device access rule and/or change the global access policy so that a device will otherwise be blocked (or quarantined).

To understand the action taken by Exchange when a device attempts to synchronize, I have made my own flowchart (click to zoom):

How to fix your presumably bricked Wizard

Posted on by — No Comments ↓

Recently I have been using various betas of CRACING’s CR96 Touch HD builds of Windows Mobile 6.5. When I tried to install 6.5.0.2.9, RUU kept crashing on my Windows 7 x64 workstation. I am pretty sure I installed previous CR96 Touch HD betas aftering installing Windows 7. I tried application compatibility when running RUU (XP SP2), running as administrator, different RUUs, all with the same MFC application error.

I sent time trying to get an RUU to run successfully, but then went on ShellTool. I started flashing the new ROM with it, but after an hour it was still sitting there. I disconnected the Wizard and either soft- or hard-reset the phone. Now it got ugly. The boot screen would come up, displaying the IPL,SPL,Radio, and OS (the latter being 6.5.0.0), but it would never go past it.

I was able to boot the Wizard into the bootloader, so I tried MTTY. I couldn’t get the USB port to be listed in the drop-down, thinking it was something with Windows 7 or x64. I then went on to nueTTY [link no longer available]. I was able to connect with it, so I ran d2s, which backs up the on-chip ROM to SD. This was successful in that I was now able to put a ROM on the SD card and boot into the bootloader, which prompted me to flash the ROM (I could not get it do this prior to running d2s. Unfortunately, now booting showed only an IPL, SPL, and Radio version….no ROM version installed.

Telling it to flash the ROM resulted in the BINFS being written successfully and then immediately failing with a checksum error. Now I was really stuck. I couldn’t get RUU to run, couldn’t flash from SD card, there is no OS on the device anymore, and I couldn’t find anything helpful while using TTY. So I finally decided to try Windows XP Mode in Windows 7. After getting that installed and running, I installed ActiveSync 4.5. Running the RUU that came with 6.5.0.2.9 only resulted in errors about needing a newer RUU. I figure this had something to do with the fact that I no longer had any OS on the Wizard. But RUU didn’t crash, which was a good sign. I tried nueTTY again (which needs .NET FW 2.0 and VSTO 2008 runtime). It could see the Wizard connected, but then dropped right back to a command prompt. I tried MTTY again, learning that USB will only show up as a valid port if the ActiveSync processes are killed. MTTY connected, but I couldn’t find any commands that would help me.

Still with me? Well, we’re on the final leg now. While still using Windows XP Mode, I ran the RUU that is for the Wizard and doesn’t do any CID checks. This time it detected the Wizard and flashed 6.5.0.2.9 succesfully! Finally! That was a harrowing couple of days.

So, what are the key takeaways from this? No, it isn’t “Don’t flash with cooked ROMs that are only in beta.”

  • Be sure to kill the ActiveSync/WMDC processes to get MTTY to see the USB port.
  • Connecting to a Windows Mobile device works just fine in Windows XP Mode; the Pocket PC USB Sync driver will be installed automatically once you attach the port in the USB menu of Windows XP Mode.
  • Running a terminal program, such as MTTY or nueTTY, really can brick your phone if you don’t know what you’re doing.
  • The No ID version of RUU for the Wizard is always good to have on hand.

My aging Wizard is now running IPL and SPL 3.08, radio 2.19.11, and CR96 Touch HD ROM 6.5.0.2.9 beta. My Tilt is running HardSPL 3.29, radio 1.70.19.09, and shifu’s 3.2 ROM (6.5).

Stop ActiveSync from opening an Explorer window when a device is connected

Posted on by — No Comments ↓

Does connecting and/or disconnecting a Windows Mobile handheld to your desktop result in an Explorer window opening? It has been happening to me for so long, and it is really annoying. Long story short, this is caused by a registry entry.

Navigate to HKLM\Software\Microsoft\Windows CE Services\AutoStartOnConnect. You will see a value for (Default) with the data set to what appears to be null (nothing visible in the data field). Click on the (Default) name and then press the delete key. This will change the data to be (value not set). If the same thing happens when you disconnect your handheld, do the same thing in the \AutoStartOnDisconnect key. The change takes effect immediately.

Pocket Controller skin for AT&T tilt

Posted on by — 1 Comment ↓

If you use SOTI‘s Pocket Controller Professional to control your Windows Mobile device from your desktop, you know that you can display the screen in a skin and control the virtual hardware buttons in PCP.  You can download skins from within PCP, but only during the first year of purchase.  They consider the skin catalog a "service."  After the year is up, you have to purchase the application again (at an upgrade price), which includes product upgrades for the year, too.  However, PCP hasn’t even been updated in a year, so it seems a pretty cheap way to earn revenue, considering SOTI even solicits images from customers to add to the skin catalog.  (They used to provide the entire skin catalog free of charge.)

My work installation is beyond the one year of service, so I couldn’t download a skin for my AT&T Tilt.  My home installation (separate license), however, was within the service year, so I downloaded the skin and copied it to my work installation.  I could not find anything in the program or on SOTI’s site regarding copyright of the skin images, so I am posting the Tilt images (displayed half-size) for anyone who needs it.

Tilt vertical image

Tilt horizontal image