Friday 29 June 2012

How Microsoft need to get Surface right to make an impact on the tablet space

I'm excited about the release of Microsoft's Surface (tablet) as it could make a real difference to me and become the most popular tablet in the enterprise space.


Working as an IT engineer/manager I need a tablet that I can install all my usual support apps such as RDP (via gateway), putty, Cisco VPN client etc. I've considered an android tablet and played with the Samsung Galaxy Tab.  Apart from the fact the Samsung takes so long to charge, doesn't last any time on battery and is a bit bulky there are other reasons I'm not going to purchase an android tablet.  They're good as a more casual device for games, apps and browsing but when it comes to using in an existing Microsoft infrastructure its not all plain sailing.  


Yeah sure you can find apps that do RDP, but to be honest I don't trust where my traffic is going and no-one seems to offer an RDP client that can connect to a RD Gateway.  Also VPN clients, there are various options available but once you're connected your tablet isn't part of the domain so you have to re-authenticate every time you want to access something different.  I know there are various apps which allow telnet and ssh connections so that one isnt really a problem.


As for the Ipad, I just don't want one. So restrictive, and Apple deciding what apps they allow is frustrating.  Also whilst you can introduce a business app store its just something else to install and manage.  


So why do I think Microsoft could get it right.  Well people like what they're used to. If you could have a Windows tablet, which can be part of the domain and where can use all your existing apps then it should be a real winner for use in the enterprise.  You can secure it as you would any Windows PC, you can configure with group policy, SCCM and the like, everything would just work.  This could be a real winner for Microsoft.  


There are though a couple of things they need to get right.  I don't see a place for Windows RT in the enterprise, its just too restrictive.  The Windows 8 pro model would be ideal but the price needs to be below the £400-£500 mark otherwise it wont get good adoption. I've seen comments that it could be upwards of £600 - this just isn't going to work for Microsoft. Also the metro style should work well on Surface, unlike with Windows 8 on a desktop - there's just no place for that but thats another story.  


Also I think Microsoft have got to realise that people aren't going to continue to pay hundreds of pounds for things like Windows or Office, the prices need to come down significantly and Office should be installed by default on the Surface (I'm not expecting full blown office but at least Word,Excel and Outlook.  If they can realise they need to reduce prices then that brings the cost of the Windows 8 Pro Surface down to match other popular tablets.  If they did this I could see a real case for introducing in my workplace - sales people would want them, execs would want them, and use mere support type people would definitely use them.  It would make being on-call a whole lot easier :-)



Thursday 5 April 2012

Unable to send to recipients who use Messagelabs following Exchange 2010 Service pack 2 update

Just installed Exchange 2010 SP2 on our hub server and all hell broke loose.

We use Messagelabs' email antivirus and antispam and had Messagelabs configured on our send connector.

Set the send connector to send directly using MX records and all was ok except any domain which was also using Messagelabs' services.

It looked like Messagelabs had gone down because I kept getting 451 4.4.0 Primary target IP addresses responded with: "421.4.4.1 Connection timed out"

Set the SMTP protocol logging level to verbose and in the logs it was obvious what was going on :

2012-04-05T10:30:11.657Z,SMTP to Internet,08CEE1280B00A50C,2,10.0.0.16:59759,85.158.139.19:25,<,220 server-3.tower-178.messagelabs.com ESMTP,
2012-04-05T10:30:11.657Z,SMTP to Internet,08CEE1280B00A50C,3,10.0.0.16:59759,85.158.139.19:25,>,EHLO xxxxxxxxxxxxx.com,
2012-04-05T10:30:11.688Z,SMTP to Internet,08CEE1280B00A50C,4,10.0.0.16:59759,85.158.139.19:25,<,250-server-3.tower-178.messagelabs.com,
2012-04-05T10:30:11.688Z,SMTP to Internet,08CEE1280B00A50C,5,10.0.0.16:59759,85.158.139.19:25,<,250-STARTTLS,
2012-04-05T10:30:11.688Z,SMTP to Internet,08CEE1280B00A50C,6,10.0.0.16:59759,85.158.139.19:25,<,250-PIPELINING,
2012-04-05T10:30:11.688Z,SMTP to Internet,08CEE1280B00A50C,7,10.0.0.16:59759,85.158.139.19:25,<,250 8BITMIME,
2012-04-05T10:30:11.688Z,SMTP to Internet,08CEE1280B00A50C,8,10.0.0.16:59759,85.158.139.19:25,>,STARTTLS,
2012-04-05T10:30:11.719Z,SMTP to Internet,08CEE1280B00A50C,9,10.0.0.16:59759,85.158.139.19:25,<,220 ready for TLS,
2012-04-05T10:30:11.719Z,SMTP to Internet,08CEE1280B00A50C,10,10.0.0.16:59759,85.158.139.19:25,*,,Sending certificate
The server was trying to negotiate a TLS session.
Checked the settings on the SMTP connector in the EMC but not configured to use mutual TLS.
Used get-sendconnector powershell and also saw it was set to false. Then I spotted that the ignoreStartTLS setting was set to false. Messagelabs issues STARTTLS and so our server tried to connect using our certs which aren't quite right for TLS.

Ran set-sendconnector -id "SMTP to Internet" -ignoreSTARTTLS $true and all now working. This must have changed as part of the SP2 install because I didn't change it.

Am happy again now. Hope this helps someone else out there.

Friday 13 January 2012

Sharepoint Search not working - Start address sts4://servername/contentdbid cannot be crawled

I've spent a lot of time with sharepoint and when it works it works well but we keep having search issues with one of our sharepoint sites.

In the eventlog and sharepoint log files I get the following error:
The start address sts4://servername/contentdbid={66e8aaa2-3335-40fb-a679-41731a41d83b} cannot be crawled.
Context: Application 'Serve_search_queries_over_help_content', Catalog 'Search'
Details:
The object was not found. (0x80041201)

There are lots of posts about disabling loopback checking, and rebuilding search indexes around but my scenario is slightly different and didn't fall into these categories, although I DID disable loopback checking as part of the work towards the fix so that MAY BE REQUIRED.

I tried browsing to the URL that it mentioned and it didn't work. I didn't expect it to but I thought maybe its searching an old sharepoint site so concentrated on trying to find out how to rebuild the index. I couldn't find anything.

So then there was some mention of Alternative Access mappings and thats where I found the solution.

Our server is running Sharepoint Foundation Server 2010
It also hosts a number of other sites. We're using host headers to point users to the right site.
We're using a different URL (the host header) for accessing the sharepoint site.
So when I browse to http://servername I get nothing - to be expected. Thats when it hit me, its trying to access the site using the wrong URL.

What had happened is that for some other reason we'd changed the default URL in the Alternative Access Mapping to be http://servername and set an internet URL of kb.abc.com

What I did to fix the issue was set the default to http://kb.abc.com (this is the host header used for the site) and set the intranet URL to http://servername (although this wont work because its not in the host headers - I guess I could have added that too).