Review: HTC Touch Pro 2

OK, having only had it for 24 hours, I can't really give the HTC Touch Pro 2 a full review, but here goes:

Overall, I like this device, based on WinMo 6.1 Pro it's a full featured PDA with full Email, Calendar, Task and Notes syncing. The keyboard is great and the screen is big, bright, clear and hi-res (320x800), way higher than Boss. The phone call quality seems OK, though I see myself using a headset more and more, which further improves audio quality.

With MS rolling out it's Marketplace for WinMo (designed for WinMo 6.5, but able to be installed into 6.1), I can see a steady stream of Apps becoming available in a single location, though most, I suspect, will cost.

I installed Skype and the Windows Live Mobile suite (primarily Messenger), both of performed perfectly.

Microsoft MyPhone also works quite happily and even gets the right phone image (the Boss photo is wrong).

With about 240megs available for installing Apps, there's quite a bit of space, though I could see myself dropping in a 2Gig+ micro SD card and using that for storage and as an install location for Apps (thereby maximising RAM for running Apps and storage of programs/content that can't be redirected to the SD card) and storage of MP3s.

WiFi worked fine, though Apps seem to need to be aware of which connection (WiFi, Desktop, 3G) to use, rather than some kind of built-in least-cost weighting.

Having a built-in FM radio was novel and as long as the headphones were plugged in, it seemed to get sufficient reception in most places. You could also switch to the built-in (stereo) speakers, though the headphones must remain attached as they're used as the aerial.

Loved the Google Maps based navigation which is GPS aware and it happily tracked me home on the bus, with between 5 and 9 GPS satellites available, though the powersaving kicking in was a pain, so if you plan to use this as a navigation device in your car, make sure you have a car power kit and set the powersaving to do nothing while connected to power.

I can see this becoming a very powerful (it's actually quite fast), flexible device, a likely flagship WinMo device.

Where it starts to suffer is under some of the newer functionality. WinMo 6.1 Pro, while touch screen orientated, isn't particularly smart and so things like the on-screen keyboard, clicking links in a browser, etc, aren't always as "easy" as they should be, requiring you to use the stylus. I believe this is revamped in WinMo 6.5, which is available for the Touch Pro 2, but is yet to be "blessed" by Telecom. Similar issues exist with UI performance, with small, but highly irritating lag every now and then (again, I believe this is fixed in WinMo 6.5), the accelerometer is also limited to Apps that are aware (IE wasn't, Opera was, Email/Outlook wasn't) even though sliding the keyboard out always switched the orientation. The lack of type-ahead on the keyboard was annoying after the Boss, but may have been just a setting (and I've seen this going in WinMo 6.5).

In 24hours, I can't say much about the battery life, though both 3G and WiFi seemed to noticeably drain it.

As a phone, it's hefty, both big (primarily the depth due to the slide-out keyboard) and heavy, though it feels fairly solid, except the battery cover seems to look (and at times feel) like it's about to pop off… which did happen once.

The included "wallet" is unhelpful, though protective. It adds to the bulk and weight, while not allowing you to see the phone status (flashing lights), nor can you charge it, connect the headphones or clip it to your belt.

Over WiFi I couldn't connect to my home PCs, though this isn't something I've tried before, so I may have been doing something wrong (just wanted to mount up a share, rather than downloading Apps of the internet, directly onto the device.)

I also found the sliding keyboard mechanism a pain. Having gotten used to the Boss, having the keyboard slide the otherway felt counter intuitive and the action was quite jerky, leading me to often end up pressing keys or the screen. And if the headphones (or charger/sync cable) is attached, it gets in the way of your right hand, making handling the device awkward.

I would have loved to flash it with a "cooked" WinMo 6.5 ROM, as I suspect this would have resolved some of the usability related issues. Though that would of course void any warrentee with Telecom…

Still, it's no iPhone (though thanks to HTC it tries quite hard), but is very corporate. Perhaps it's waiting for two things: WinMo 7 and a thinner, lighter revision of the hardware.

Hmm so much for a mini review

DIY Dilbert RSS Reader for SharePoint 2007

 

Everyone seems to be jumping on the "Here's my custom web part to do this…" band-wagon, so here's my "Here's how to do it out of the box…"

Everyone loves Dilbert, and Scott Adams has been on the money for so long, it's a wonder he isn't a gazillionaire…

Various people have posted ways to get around the fact that the out-of-the-box RSS Reader in WSS 3.0/MOSS2007 doesn't display the images from the Dilbert.com
RSS feeds, unless you expand the item. Their primary solutions are based around new web parts, or worse. But why bother? Most of them aren't packaged up properly, so require a skilled and privileged user to set them up.

Here's my solution, all it requires is the ability to add the built-in RSS Reader to a page and that SharePoint can already access, external to your organisation, RSS feeds (usually requires some proxy details in the web.config).

Steps:

1. Create a new blank web part page or edit an existing one (e.g. the default page on your MySite).
   
2. Add a Web Part to the appropriate zone (preferably a wide zone)
   
3. Tick the RSS Viewer Web Part, click Add.
   
4. On the newly inserted Web Part, click edit | Modify Shared Web Part (or click Open the Tool Pane)
   
5. Type the feed URL (e.g. http://feeds2.feedburner.com/DilbertDailyStrip )
   
6. Limit the feed to how ever many strips you want to display at once (e.g. 1)
   
7. Click the XSL Editor button
   
8. Copy and paste the XSL into something useful (at worst, there's always notepad)
   
9. Search for: toggleitemdescription
   
10. And replace:
    
    <div class="item link-item" >
    <a href="{concat(&quot;javascript:ToggleItemDescription('&quot;,$CurrentElement,&quot;')&quot;)}" >
    <xsl:value-of select="rss1:title"/>
    </a>
    <xsl:if test="$rss_ExpandFeed = true()">
    <xsl:call-template name="RSSMainTemplate.description">
    <xsl:with-param name="DescriptionStyle" select="string('display:block;')"/>
    <xsl:with-param name="CurrentElement" select="$CurrentElement"/>
    </xsl:call-template>
    </xsl:if>
    <xsl:if test="$rss_ExpandFeed = false()">
    <xsl:call-template name="RSSMainTemplate.description">
    <xsl:with-param name="DescriptionStyle" select="string('display:none;')"/>
    <xsl:with-param name="CurrentElement" select="$CurrentElement"/>
    </xsl:call-template>
    </xsl:if>
    </div>
    With:
    
    <div class="item link-item" >
    <xsl:call-template name="RSSMainTemplate.description">
    <xsl:with-param name="DescriptionStyle" select="string('display:block;')"/>
    <xsl:with-param name="CurrentElement" select="$CurrentElement"/>
    </xsl:call-template>
    </div>
    
11. At this point, you could also do the same for the RDF and ATOM sections (keep searching for toggleitemdescription), just for the sake of completeness.
    
12. Copy and paste the XSL code from your editor, back into the XSL Editor (in SharePoint)
    
13. Click Save
    
14. You can now make any other changes to the Web Part (say restricting the chrome) and click OK
    
15. Check-in/publish/Exit Edit Mode and you're done
    

All this does is stops the Web Part from collapsing the RSS items, which in Dilbert's case, means you get to see the images. The down side, is that it still ends up displaying the date to the left of the image. So not clean, but it works and it's out-of-the-box.

You could dig around in the XSL a bit more and probably find a way to get rid of the date.

If you want to use this over and over again, just export the web part, and import it again, giving it a unique name and next time just use your new one. No special privileges required (at least not on your MySite) and no DLLs, no config editing, just nice and easy.

I really should look into how XKCD.com does their feeds, as the RSS Viewer web part has no problems at all with displaying the images.

The wonders of Kerberos, SharePoint and SQL Reporting Services

OK, so we’re trying to get a little more modern here, decreasing our reliance on Oracle Reports (yetch!) and Access based reporting (shudder) and move on to the spiffy SQL Server Reporting Services, only 2005, but hey, we have to start somewhere.

Given that our Intranet is SharePoint based (full MOSS2007), I of course wanted to run SSRS in integrated mode, so along came Kerberos.

I’ve had Kerberos working for SharePoint for some time now, so thought it would be a doddle to get SSRS integrated, boy was I wrong.

First up, turned out that none of our SQL servers had registered server principal names with AD, so:

Setspn –a MSSQLSvc/NETBIOSNAME_IN_UPPERCASE:PORT DOMAIN\DOMAINACCOUNT_THAT_SQL_IS_RUNNING_UNDER
Setspn –a MSSQLSvc/FQDN_NAME_IN_UPPERCASE:PORT DOMAIN\DOMAINACCOUNT_THAT_SQL_IS_RUNNING_UNDER

Note: the inclusion of the PORT, not all of the documentation mentions that for SQL…
Note: uppercase – yes, dispite the MS documentation stating that “as long as you’re only using Kerberos against Windows machines, it’s case-insensitive”, I found that it didn’t work until I pushed the case up. No I haven’t tried combinations of case to find exactly where the case is important. Though according to the Kerberos tickets on my PC, my domain ticket has an all uppercase domain, but one of my SQL tickets has only the server name (and not the domain) in uppercase… go figure.

Having discovered the case sensitivity, I had to go back and re-do all my SharePoint SPNs and just to make sure, I doubled up on the ports too:

Setspn –a HTTP/NETBIOSNAME_IN_UPPERCASE DOMAIN\DOMAINACCOUNT_THAT_THE_SP_APPPOOL_IS_RUNNING_UNDER
Setspn –a HTTP/FQDNNAME_IN_UPPERCASE DOMAIN\DOMAINACCOUNT_THAT_THE_SP_APPPOOL_IS_RUNNING_UNDER
Setspn –a HTTP/NETBIOSNAME_IN_UPPERCASE:80 DOMAIN\DOMAINACCOUNT_THAT_THE_SP_APPPOOL_IS_RUNNING_UNDER
Setspn –a HTTP/FQDNNAME_IN_UPPERCASE:80 DOMAIN\DOMAINACCOUNT_THAT_THE_SP_APPPOOL_IS_RUNNING_UNDER

And now it all works, yay, with the current user authenticating all the way back to the DB.

Only took a few days to track that down. Kudos to the MS team producing the Troubleshooting Kerberos Delegation in Windows document which took me through a very rigorous set of steps to ensure I was configured correctly (though more help on what Kerberos should look like in NetMon would be good!) though doesn’t mention case-sensitivity, had to dig that up HERE.

Now we can get back to concentrating to actually delivering reports…