Transitioning to Offce365

If your organization just transitioned to Office365, please be aware that there are some recent changes in Office365 which has come to our attention which may cause you to see an error when performing the quick configuration.
This error shows up as an error code 451 when performing the configuration if you used the server name as m.outlook.com

We have uploaded a beta version which overcomes this error. The beta is available at the following locations
For Smartphones : http://nitrodesk.com/tddownloads/nitroidbeta-droid.apk
For Tablets (honeycomb or higher) : http://nitrodesk.com/tddownloads/nitroidbeta-honey.apk

If you install the beta version, the 451 error should go away and you should be able to configure normally.

Syncing status with exchange servers

Lately we have been receiving a lot of support requests around this issue, and hence this post. Please read carefully, support may be simply unable to fix your issue. TouchDown has been tested to make these status changes to the device and back. However, there are factors that are outside our control that may cause some of these updates to simply not work. While support will try to establish a cause, we are typically unable to actually solve issues which are outside of the applications control.
Basics
TouchDown never talks directly with your outlook on the desktop. Outlook and TouchDown are simply "clients", which display what they think the exchange server account contains. The source of all the data is the exchange server which you connect Outlook and TouchDown to. There may be times when either of them may be out of sync with the server.

How to see what the server really knows
In order to see what the server knows about your data, you must connect directly with the server. The best (and only) way to do this is to login to OWA, or (Outlook Web Access). OWA is NOT OUTLOOK. For this, you must first find out the OWA link for your exchange server. If in doubt, ask your administrator, the link may take the following forms
https://mail.company.com/exchange
https://webmail.company.com/owa
(in some installations where security is not a priority for the organization [or where the administrator may find it desirable to have all your data to be trasmitted in plain text over the internet for some odd reason], https may be replaced with http.)
Once you know what the link is, you should navigate to the link on a PC browser. THe server will at that time ask you to authenticate yourself. Once you login to the server, you will see a view much like outlook, but inside your browser. What you see in this view is what the server knows. Any changes you make here will eventually be reflected in outlook and touchdown if all is configured correctly.

How read status (and deletions) works on Exchange
Outlook to Device
When you mark an item as read on Outlook, outlook eventually sends the status change to the exchange server. The exchange server maintains the status of each of the emails on the server, and eventually sends the status change to the device, IF it determines that the device is displaying the email

What can go wrong
1. Outlook fails to update the status on the server for some reason. To find out if this is the case, you have to see what exchange sees. After you mark items as read/unread in outlook, if you dont see the changes reflect back in TouchDown, login to the server and see if the server shows the items as you marked them. If it doesnt, chances are outlook did not update the server correctly. Make sure that you allowed enough time for Outlook to actually mark those items on the server.
2. Outlook updated the server, but the server did not update TouchDown. This can happen because the server doesnt always immediately update the device for changes like a read status change. Typically such changes are delayed to prevent too frequent updates to the device in an effort to save battery life. In such cases, changes such as these MAY be delayed until a more significant change such as a new email, new contact, a new event etc are detected. You can however force touchdown to proactively check for changes by pressing Menu/Sync on the TouchDown main screen a couple of times.
3. You deleted an item, but it still appears in TouchDown because you may be syncing the Deleted Items folder in TouchDown. This is by design.
4. There are some other lesser known and encountered situations where this may happen, such as cases where there may be multiple devices syncing to the server and the server faces internal issues when updating all devices involved. For example, we have known one or two situations where users have had this problem go away after they removed other devices from syncing with the exchange server. But that does not necessarily mean you cannot sync  multiple devices. (In our test environments, we have up to 10 devices syncing flawlessly with the server with no such issues).

Device to Outlook
When you mark an item as read on TouchDown, by default TouchDown does not immediately tell the server about the change. This is again to prevent unnecessary chatter with the server. TouchDown will batch all such changes are send them out the next time a more significant event like sending an email, or when a change is detected on the server. You can change this behavior somewhat by turing OFF the "Defer server updates" option in the last tab of touchdown settings.

What can go wrong
1. Defer server updates can cause batching of updates to the server, meaning that the changes are not immediately sent to the server. Turning it off, or going to the main touchdown screen and doing a Menu/Sync can send such batched changes to the server.
2. TouchDown faces an error from the server when sending the updates. Such errors are typically due to situations where the server returns an error, or is unavailable. While rare, such situations can in some cases cause the change to be lost in transit. With a good internet connection and a reliable server, such situations are almost non existent. In cases where the internet connection on the device is unavailable, touchdown would either wait for a connection or retry the operation for a finite number of times before giving up.
3. TouchDown updated the server, but the server did not update outlook. This is completely out of our control, since TouchDown's work is complete once the change has been sent to the server and acknowledged. if outlook has not updated the change from the server, you can confirm that issue by looking at OWA as described in the earlier section

TouchDown on ICS

Now that ICS is available, and devices are shipping, thought i would write a bit about TouchDown on ICS devices. There is a fair amount of confusion about what version of touchdown should be used on ICS devices. ICS can run on smartphones as well as tablets.

There are two flavors of TouchDown in the Android Market

1. TouchDown For Smartphones (optimized for phone form factors)

2. TouchDown HD For Tablets (Optimized for tablet form factors)

After playing with both versions on the Galaxy Nexus, i am leaning towards using TouchDown For Smartphones on the device. The main reason is that the TouchDown HD For Tablets, being a honeycomb build takes up a sizeable chunk at the top of the screen to show the action bar, which does not really add much value to the application except provide a way to access the menu options. However, If you run TouchDown for Smartphones on the Galaxy Nexus, the menu would be accessible from a button which looks like a ":" at the bottom right of the screen. I find that wasting a whole row for the menu options was not really worth it.

Tablet mode Screen Display Please note also that when run on the Galaxy Nexus, the TouchDown for Smartphone version will by default open into a split screen view after you restart the application after the first configuration. If you find yourself opening the app into tablet mode, you can go to settings and under advanced tab, check ON the "Disable Tablet Mode" setting.

While the device has a high resolution, it doesnt really have enough surface area to display usable information in this format. To fix this, we are updating version 7.1.009b (this is beta still) to detect physical screen sizes less than 5" when running quick configuration, and automatically turn on the "Disable Tablet Mode" option in the advanced tab of settings.

Here are some screenshots of how the two versions look. To get this exact look and feel, note that you should TURN OFF the "Disable tablet mode option" in the last tab of settings. Tablet mode will be disabled automatically on the device since these views are not ideal.

First is a sample screenshot of TouchDown HD for Tablets showing the split screen view. Note that gray bar on the top plus the navigation tabs which take up too much space.

Here is how the TouchDown for SmartPhones app shows up on the device. Note the : symbol at the far right bottom. Thats the menu button. Also note that these screens are captured using the Black Theme. Read below to see how to set themes.

This is the email list in split screen mode.

Same thing viewed horizontally

Calendar Viewed Horizontally

Now, the classic main touchdown screen, this is the screen you will be normally greeted with after configuration.

Switching Themes

If you want to change the themes on the touchdown main screens and the list views, you can open settings and tap on the Select Theme option shown in the image below.

Note about the DeviceType change in the next version.

In the next version of TouchDown, we are changing the default device type reported to Exchange from "Android" to "Touchdown".  While this will not affect an already configured device, if you uninstall and reinstall or reconfigure the device from a clean state, the new string will be reported to the server. Admins can now use that string to better identify TouchDown in Exchange Server ABQ settings.

 Screen Capture Security Hole : We think it is dangerous to let android let you accidentally capture your email screen to the SD card if you happen to hold the volume down and the power button for about a second. Hence, we have put in some measures to ensure that if your security policies have PIN or data encryption or SD card encryption enabled, you cannot accidentally take screenshots of the touchdown screens that display potentially sensitive information. We have verified this on ICS.

Version 7.1 is available

Version 7.1 has been released to the market(s)
The following are the notable changes
- Support for themes (go to settings and in the advanced tab you can select themes)
- Support for Quick Replies by long-pressing the email in the list.
- Configure quick replies by going to the last tab of settings and clicking the quick replies button
- Fixes a MAJOR DLP SECURITY HOLE in some android devices. On some devices we found that regardless of the security level in your enterprise, a hotkey combination (on some devices, an easy to click button at the bottom) is all it takes to send your secure email as a JPEG image into your gallery. This image compromises security in all sorts of ways. This issue will become worse with the release of ICS, which makes the screen capture function a part of the OS itself.

Can enterprises embrace the Amazon Kindle Fire ?

The Kindle Fire has finally been released, and has made its way to the hands of hundreds of thousands of customers. While it is not known how many of those users are going to bring the device to the enterprise when holiday season is over, it is only logical to assume that there will be thousands of devices making their rounds inside the corporate firewalls across America at least for now.

Google News technology sections are filled with reviews both positive and negative around the device. Mostly positive. After all, the press has been waiting for link bait like this for a while. After the initial obligatory reviews around the device itself, attention is slowly turning towards whether and how well the Fire can adapt to the enterprise. Despite being a glorified electronic shopping cart for amazon, the Fire is still a formidable contender in the android tablet space. Will enterprises embrace it with both hands, or will it fizzle at the enterprise doorstep ? No one knows for sure.

From where we stand, we see IT admins may have little choice but to work backwards from the device and find creative ways to ensure they can support the device. At the end of the day, when the CIO gets a fire for christmas, its pretty much game over, you have to suport it.

As far as device capabilities go, the Kindle fire is a first class citizen in the Android world. it runs Gingerbread, and there is no excuse for not supporting the fire just because it has been heavily customized by Amazon. Amazon has done a great job of changing the OS on the surface to make it friendly for end users, but has not really backtracked on the underlying capabilities of the OS when it comes to security and sandboxing. So it can be made as secure as Gingerbread on any other phone the user may purchase. The fact that most MDM vendors have not taken the effort to test on the fire and publish their agents on the Amazon Market is probably less Amazon's fault and more a factor of prioritization by the MDM vendors. The vendor that makes the necessary investments to support the Fire and to get the MDM agent published on the amazon appstore for android will be met with eager enterprises wanting to support the device.

As always, NitroDesk TouchDown runs on the Kindle Fire with no reduction in functionality or security. From TouchDown's point of view, the fire is yet another tablet running android Gingerbread. The Fire does not have a built in Exchange email client, does not have a calendar application built in, but it has all the necessary underlying support for TouchDown to provide push email and a sandboxed contact/calendar/task/note database to customers who want a tablet experience on it. In fact, TouchDown is the only available exchange activesync client which can provide a full screen tablet optimized experience on the Fire. The only shortcoming on the device we have observed is the inability for the device to maintain a Wifi connection when the device is asleep, preventing push mail from working in that state. We have worked hard to ensure that the Fire is supported as a first class device with all the encryption and security support that the enterprise needs. Any MDM which touchdown integrates with, that publishes their agent on the Amazon AppStore will be immediately supported by NitroDesk.

TouchDown for the Kindle Fire!

The Kindle Fire ships today, and alongwith it we have updated the latest version to the Amazon Market.
This new version is designed to play well with the Fire, and support a split view a'la the tablet versions on the Fire.
This is the original full blown touchdown feature set, so all the security mechanisms will be in place, ensuring that you can take the device to work if your organization approves of TouchDown.

More information at http://nitrodesk.com/fire.aspx

Enjoy that awesome device!

Version 6.4 is here

TouchDown Version 6.4 has been published
There are a ton of fixes, most notably improvements in push reliability and protection against some database corruption scenarios and exceptions when composing emails.
New features include
- Ability to sync SMS when using exchange 2010 and Outlook 2010
- Support for Sybase Afaria MDM
- Support for viewing and sending S/MIME signed emails (encryption is not supported at this time)

Honeycomb, finally here !

Got the HoneyComb SDK yesterday. As developers, it is a relief to be able to get our hands on a preview SDK before the devices go out. Kudos to Google for making such a monumental effort to make it available in a relatively good shape. Impressive developer docs and samples too.

One little glitch though, as acknowledged in the release notes : it is DOG slow. But then again, that's what faster PCs are for, right ?

Had to run out to the store and pick up a screamer to start working on the SDK rightaway. If you want to know what it takes to develop on it relatively painlessly, here are the specs, and with this, you can get it runnning at around half the speed of the original android 1.0 emulator on a Core 2 duo.

• Intel i7 950 @3.06GHz 8Mb


• 6Gb Ram


• kingston 64Gb SSD (for eclipse, emulator, build environment, as well as the OS swap files)

New Fragments concept is great, but truly wished it was a subclass of activity, so developers could reuse all the existing code rather than rewriting/refactoing it all. I think we will stick with our own ActivityGroup based Fragments mechanism for now.

Good to see someone is thinking about device level encryption, but unfortunately not ready for primetime yet. However, for Honeycomb versions, we will make use of the OS level PIN policies, since FINALLY they have become trustworthy for those pesky Complex PIN security policies.

Hopefully will have a separate honeycomb ready beta in a week or so for those who already have a real device (wish we had one, but we are mere developers) :-(

S/MIME support and SMS Syncing

Really excited to introduce support for viewing S/MIME signed or encrypted emails, as well as the ability to take advantage of the SMS syncing capabilities of Exchange server 2010.
These features are not yet available for public consumption, but just to give you a heads up on whats coming.
Happy new year!

Money for nothing..

I was reading with great interest today on how MSFT is going to attract developers with money to fund windows phone development projects..

This, if true, is indeed great news for developers, you are now slowly the trump card for every company interested in pushing their mobile strategy. First it was Apple who intrigued you with having to sign an NDA to get a hold of an SDK to develop on the Jesus Phone. Next it was Google who let you into the game for a pidddly 25 bucks and the willingness to pick your turf and your battles. Microsoft has outdone everyone by actually offering you money to build your next big thing on their platform. Great job cutting to the chase :-)

What next? HP offering you shares in the company in return for building apps on WebOS ?

While all that jazz about Windows Phone development is cool, the tools are great, the tutorials are fantastic, and getting started videos are useful and to the point, it seems thats all you can actually do on Windows Phone - get started. Looking through the Windows phone development SDK however, makes one wonder whether you can do anything but build some cool UIs with silverlight and some games with XNA.

Maybe i have still a long way to go, but how does one indeed write a serious windows phone application without

Non-trivial networking (by non-trivial i mean connecting to a server, and getting some data, connecting to another device etc). According this this page, sockets are not supported. While it may still be debated whether HTTPWebRequests and WCF are all that is needed for the phone to support serious networking apps, i am not so sure connecting to a web server is the only type of connection which developers should be allowed to have. How are the devs gonna write remote file browsers, remote connectivity tools, cool toys that connect to other devices to share data, if you are going to always have to act like a web client.

Databases: Seriously, i hope i am just being blind here. But almost every developer on Android/iPhone is familiar with and uses the native (sqlite) database heavily on that platform. All i can find about storage on the WinPhone is how you can store "files" in your very own protected areas. No databases ? nice!

Threading : Many applications you run on Android make heavy use of threading to ensure that not all work happens while the user waits. Unable to find a real threading library in Windows Phone, i must assume that it doesnt really exist (yet?). Background threads do many things while you perform other activities : connecting to a server to check for updates, performing cleanup work for the application, backing up data, deleting temporary files and so on.

Background Services : Again, guilty as charged, i must surely be missing something. all you can build with the phone is write a cool silverlight form or an XNA application. No way for an app to hang around in the background periodically checking for messages, events, no way for an app to wake up when an SD card is inserted and perform some work, no way for listening to data connectivity changes, no way to intercept an incoming SMS.... Sure, according to the Jesus Phone, background apps are bad for the consumer, since they can cause the phone to run out of battery. Yes we know red meat contains carcinogens, but do we ban beef ? There are those consumers (android users being one group of such users) who can decide for themselves when an app is taking too much battery and uninstall such apps. No one is holding a gun to our heads..

The list goes on i am sure, i am looking at this from one perspective, with my own personal list of things i would love to build on a platform, others may see other aspects.

Bottomline? I think they should not spend money in trying to attract developers, they should instead invest all that money into making sure the platform is good and ready before thinking of wooing developers. Call the kids to a party where all you have is the clown (who by the way forgot his costume at home)
?

Surely not gonna be fun without the ice-cream..

Takeaways :

While the above may be taken as criticism by the defensive types, recognition of mistake is the first step towards glory (we ourselves try to live this mantra). Without actionable feedback, criticism is waste. So... In order to present a viable development platform for potential developers on the WinPhone, as a developer, here is the wish list :

1. Document more, document better : In case any or all of the above are false, it would be great to actually document those critical components better, clearer and more exhaustively. Omitting the critical components in initial documentation and calling it a beta will only scare away developers.

2. Review whats needed by developers : take a poll, recruit a few Android developers (you cant talk to iPhone devs, since they are under NDA), look at the android documentation for clues on what may be missing. But if you dont achieve some level of library parity, you may be actually losing a lot of potential developers. Some of these components may already be there and used by the system, they may just need to be exposed to developers.

3. Don't assume users and developers are naive : Having dealt with a few thousand android users so far, i can vouch for the fact that most smartphone users are actually smart. they know when an app is sucking their battery, and they know well enough to uninstall those. If "background apps can kill your battery" is really a serious consideration, they should revisit that. (if it is just an excuse for "we dont want to figure out to do it", thats a different story) I dont believe a company that has produced the likes of Office and Exchange can justify punting on this one (unless its simply a matter of willingness. Its their platform anyways)

4. Dont shoot from the hip : yes, we all know android and iPhone are already at the party, but in the hurry to make it to the party, dont forget the pants at home. take the time, dress to kill, then get in that car. We aren't going anywhere. A late but good release is always better than an early release which fails to launch.