Azure File Sync - Cloud Tiering but drives full

Azure File Sync is a really useful technology especially if you have file servers with lots of files which are not used very often.  With cloud tiering enabled you can reduce drives with terabytes of data down to gigabytes. 

But there is one thing to watch out for if you have hundreds of thousands or millions of files.

If you have for example half a million files and find that a 30GB drive is filling up even though you have cloud tiering enabled at say 80% then you've run into the same issue that I did. 

I spent weeks working with Microsoft to try and figure out why it looked like cloud tiering wasn't working. I could see all the files were offline with APLO attributes but still the disks were full.  I'd picked this server up from someone else and hadn't noticed how the disks had been configured. 

They'd been formatted with 64k allocation unit size.  This meant with half a million files they were using over 30GB of space.  Reformatted to 4k block size and now my disks are less than 20% full.

Start menu and Appx broken on Windows Server 2016 (with Citrix installed)

I'd been trying to fix an issue with some servers where 

• the Start Menu wouldn't work
• unable to right-click any icons on the taskbar (to runas administrator etc)
• any metro style app fails to load
• ms-settings: doesn't work

I'd tried all the usual fixes, sfc /scannow, dism checks and restores.  Finally I identified that its an issue caused by Citrix XenApp 7.15.2000 (https://support.citrix.com/article/CTX237192). 

Get-appxpackage returns nothing.  Trying to repair appx packages using powershell and add-appxpackages was failing with error 0x80070002 

Contacted Citrix they said I'd need to contact Microsoft to fix. Helpful!

Finally found the issue, which was a combination of suggestions I'd found elsewhere but here's my solution

You need a server where it works to export the registry keys. Obviously suggest that this is the same version of Windows.

• Export the registry HKLM\Software\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore from a good machine
• On the server which has the issue take ownership of the same key, and give your user full permissions.
• Import the registry file you exported from the other server.
• Then in Powershell running as admin:
• ((Get-ChildItem "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\InboxApplications") | Get-ItemProperty).Path | Add-AppxPackage -Register -DisableDevelopmentMode 
• Set ownership on the key back to SYSTEM

Providing there are no errors your start menu should return to normal.

Hopefully this helps someone else who has spent many hours trying to fix the same issue.

Adding certificates to Azure Automation was not easy

Ok, so I decided I wanted to start looking at Azure Runbooks.  I thought rather than do what I normally do and go in blind without any knowledge on Runbooks that I'd first watch some of the free stuff on Microsoft Virtual Academy.  Apart from being easily distracted when sitting there watching people talk it helped me understand why I couldn't get to my subscription (ok you got me, I did try and have a go before reading up on it).

I got to the part where you add a certificate to the Runbooks assets which you then later use for the runbook to authenticate against our Azure subscription.  'This should be a 5 second job' I thought. I'd previously created a cert from our Microsoft Certificate server and exported the PFX and set a password.

Could I upload this to the assets - NO!!  It kept complaining with :

The certificate couldn't be created. For .pfx certificate files, ensure that the password is correct.

I read some articles that said to remove special characters.  Others that said to wait 24 hours.  I couldn't wait, I tried all sorts of combinations of passwords, asset names, certificate names. Still no joy.

After several frustrating hours, I decided to raise a MS support ticket.  Whilst waiting for them to reply I decided to try a self-signed certificate and upload it.  STRAIGHT IN!!  Hooray! It worked.

So the solution is to download the SDK for Windows 8/8.1 and run makecert with syntax :

C:\Program Files (x86)\Windows Kits\8.1\bin\x86>makecert.exe -r -n "CN=DevAzureA
utomationCert" -pe -a sha256 -len 2048 -ss My "c:\temp\DevAzureAutomationCert.ce
r"

-pe - makes it exportable, the rest is self explanatory.  With makecert you get a much longer expiry than a proper cert authority issued cert anyway.

Hope this saves someone a lot of pain.

Connecting Outlook for Mac to Exchange 2010

I'm writing this article to hopefully save someone the pain that I've had in connecting a Mac to our Exchange 2010 server, because it has been painful. I've spent the past couple of weeks trying to get it to connect with some wild goose chases and in the end found a very simple solution.

The problem I was getting was whenever I tried to connect Outlook for Mac to Exchange it kept coming back with unexpected data received.  The first step in troubleshooting should be to turn on the error logging.

From the Window menu select Error Log then click the Settings cog and select Turn on Logging for troubleshooting.

The log file produced will provide some insight into what Outlook is trying to do.  Although this is where the wild goose started.  I could see that when trying to perform autodiscovery it was hitting our main website e.g. domain.com/autodiscover - this was passing back a custom page not found which I thought was causing problems for a while, so I added hosts files to point to loopback addresses which seemed to get past that bit.  Then I could see it trying autodiscover.domain.com and everything looked ok but I still couldn't send any emails.

We'd been having trouble with updates on our CAS server for sometime so I put it down to an issue with the server.  Because we had spare licenses I setup another CAS server.  But still had issues connecting.

I looked at EWS policies, made sure EWS wasn't disabled. Even checked that EWS wasn't disabled on the mailbox.

To cut a very long story short for some reason I thought about authentication.  Then I thought I'd check the authentication on EWS website.  From there I checked the IIS logs and could see 401 errors - unauthorised but no 200 successes. Then with the help of good old google found articles about turning basic authentication on on the EWS website.

set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -BasicAuthentication $true

Did this on both our CAS servers and hey presto all good.

I hope this helps someone out there.

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 :-)

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.

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).