Direct Access 2012 and Outlook RPC/HTTP

I have a client for whom i recently implemented 2012 Direct Access…. there was a number of teething problems in the implementation – but once its working, DA is actually pretty good.

If i could ask the product team for anything in DA 2012 R2, it would be

  • re-introduce wildcard certificate support (it was in UAG DA for 2008 R2, not sure why it got left out of 2012)
  • Make the status reporting dashboard check for local firewall status (that its on and that the rules have been correctly added) as part of its health check
  • Release Win7 SP2 and make it support “simple” DA auth (i know this isn’t going to happen… but it doesnt mean it wouldn’t be nice!)

Anyhoo….. at this particular client, they had decided to do one of my most hated things – use the same url internally and externally for the configuration of web services in exchange. I avoid this configuration where-ever possible…. although i understand at small sites where only one server is present – it may seem like the only option – solutions such as TMG (or another reverse publsiher), SAN certificates or creating additional exchange web services on different ports are all valid ways of getting around that config.

As to why it had been done at this client who is substantially larger…. well, the consultancy that did it…. i have very different views to them on good practices for exchange design…. and the client has a DAG without a load balanced CAS – so there is no true fail-over anyway…. grrr…. but i digress.

Due to the configuration of the same url’s internally and externally for web services, i added an entry into the DA NRPT so it would always resolve to the internal name…. issue is, that users were still getting prompted for auth, because the outlook client detected a slow connection and used RPC/HTTP, which is configured for basic auth (another config item i diagree with).

What i had not know before (because i hadnt needed to) was that you can disable RPC/HTTP on a per-mailbox basis…. using the command

Set-CASMailbox –Identity <alias> –MAPIBlockOutlookRpcHttp $True

While the better solution is to fix the exchange design (different URL’s and NTLM for RPC/HTTP) – its a handy work-around.

No more TMG

http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

very disappointing to say the least – TMG 2010 is an awesome product, but there was also a lot of opportunity for improvements. (although I had heard that this was going to happen – so its not a surprise)

of course it remains to be seen how this is handled – as far as if UAG is improved far enough to it can replace TMG…. as at the moment, in my opinion, TMG is a far superior product to UAG.

Anyhoo – disappointing, but how disappointing it is will depend on how the replacement of functionality (likely in UAG v.next) is handled.

TMG Malware inspection – blocks google with malware inspection

It looks like the latest update of the malware inspection rules for TMG 2010 blocks google.com, believing it is infected with JS/Blacole.BW.

It’s not as if many people use google… so we’ve got a couple a couple of calls about this so far…. and it looks like a few other people have run into it too.

http://social.technet.microsoft.com/Forums/en-GB/Forefrontedgegeneral/thread/e8eb8300-ecdd-4b23-b6df-f6ac0a67a226

So – the workaround

Open your TMG console

Navigate to firewall policy | Toolbox | network objects | Domain name sets

Edit “Sites Exempt from Malware Inspection”

add *.google.com

Done!

Forefront endpoint protection and logon times

Interest for FEP has increased rather dramtically lately for us… which has been cool – as unlike its predessor – FCS, FEP is actually usable! 🙂

I think this is because of two reasons:

1) FEP will soon be part of the core CAL…. (August 2011) so there are many organisations that can now use FEP and not pay any more. This is obviously very compelling when org’s can immediately save hundreads of thousands, if not millions on their current anti-virus product, by swapping over to something they already own.

2) Logon times – this is the one that has impressed me. A number of clients, particularly schools, have older hardware on which they are deploying their Windows 7 SOE’s to. When using Mcaffee or Symantec on these machines – well, they’re not overly zippy. Moving from these solutions to FEP has resulted in massive improvements in boot and logon times. For example, one school – on particularly old hardware, went from a 1:47 boot up time to a 0:46 boot up time…. logon time went from 1:54 to 0:38 (and first logon went from 5:14 to 1:55)

The times above are ofcourse only indicitive of one location, with their specific hardware etc – but for those of you not running FEP – i would strongly suggest you have a look at it. Do some logon time comparisons for yourself, tell your boss that you can save them lots of cash and that the cash should be re-directed into your pay rise!

Oh and the backend management – its now OK…. still not great… but definately usable and keep in mind that FEP 2012 is also not far away…. where the management seems to be much better again (2012 is currently in beta 2 so it may get better – and hopefully not wosre!)

Symantec Endpoint Protection and UAG SP1

Im a big fan of no anti-virus on servers…. or if you must have it, only the AV component (no network rubbish) with no realtime turned on…. if you have all your endpoints protected and entry points into the network – its just not required.

For example – an Exchange server or  a Lync server….. sure use a specific antivirus product for exchange…. but not a fucking file-level anti-virus, its just completely pointless! What are you trying to achieve apart from poor performance, corrupted databases and upgrade hassles ?

Anyhoo – today i had the fun of finding out that Symantec Enpoint Protection – bluescreens UAG when trying to upgrade to SP1. Fortunately it was a virtual – so we reverted back to a previous snapshot, removed the piece of shit, which is worse than a virus, and the UAG SP1 upgrade proceeded with no issues.

Cisco VPN client with Forefront TMG

So this one has been bugging me for a while… and then a client asked for it – so i had to get it sorted….

So it seems with some Cisco VPN connections, i can connect, but not send any traffic when the Cico VPN client is behind a TMG server. Give the VPN client a direct connection and its fine…. so after a bit of looking, i think i have it working…

1) Set AssumeUDPEncapsulationContextOnSendRule = 2 as per http://support.microsoft.com/kb/926179

2) Run netsh tmg set global name=BlockSecuredInDefaultState value=0 persistent on the TMG server – as per http://forums.isaserver.org/m_2002104621/mpage_1/key_/tm.htm#2002104688 (then reboot)

3) Create 2 publishing rules on the TMG server, one which reverse publishes IKE and the other NAT-T

UAG, direct access and bad cert names

I purchased a wildcard SSL cert today – as sooooooo many things i want to do on the corporate network now require crl’s… so i thought it be worth a little bit of money to remove the hassle of using my internal CA, publishing the crl etc.

For this, i purchased a cheapy wildcard (at $150 year) – which, for the amount of time its already saved was money well spent.

When setting up Direct Access within UAG, the group policies refused to get created, thankfully, google came to the rescue with http://terenceluk.blogspot.com/2010/09/problem-executing-generate-policy-after.html – which was dead on my issue – the cheapy cert had a comma where there shouldnt be a comma!

Anyhoo – thanks to terrance, i modified the generated ps script and away i went…. people that blog the answers to this type of thing are awesome 🙂