Apple iOS Devices can no longer access .local domain over VPN

by Ed Sparks

Apple's software quality slide continues with this recent bug that has existed in all versions of iOS 8, and is thus far unacknowledged. This appears to be related to the rewrite of much of the network stack in current versions of iOS and OS X.   

While this previously worked in older versions of iOS (up to and including iOS 7), starting with recent versions if a VPN connection is established into  a corporate LAN - and that LAN uses the (very common) .local domain for their internal DNS - name resolution will completely fail. Thus, iPhones and iPads can no longer access any of the sites or applications that rely on the internal name resolution. It appears that this is purely a code bug that causes the DNS resolver on iOS to completely ignore the recursive responses for .local requests.

An extensive thread on Apple's support forums discusses this issue, with the usual crickets response from Cupertino.

The workaround that we've successfully implemented on several of our customer sites is to add a dummy DNS zone specifically for the "local" root zone.

For example, if the internal DNS (AD) name is myclient.local, an existing forward lookup zone will be in place for myclient.local. In order for resolution to now work correctly for iOS, add in a forward lookup zone for local. You can accept all the defaults when creating, and in most cases it will be AD integrated. Then, below this new zone, add a domain (subdomain) for myclient. It is worthwhile to add in name server records into this new zone, and in some cases (depending on the internal application) it may be necessary to add host or cname records under the new zone/domain as well.

As usual, let's hope Apple eventually gets around to fixing this one.

Smarter Room and Equipment Booking Response Emails in Exchange

by Ed Sparks

Room and Equipment mailboxes are extremely useful in Exchange, especially when combined with the Resource Booking Attendant to automatically accept or reject invites.

What isn't well implemented is the ability to have the Booking Attendant respond with information that is relevant to the response.  Microsoft provide's the More Information option which allows the response to include some extra text, but this information is unfortunately sent with every response - accept, deny, or change.

For resources like conference call lines, or specialized meeting rooms with booking restrictions this can lead to confusion.  Why is the room denying my request, then sending me useful information about the room?  

Behold the Transport Rule

To work around this limitation, an administrator must instead turn to the flexibility of Transport Rules.  Transport Rules allow for the checking of the response type and then including more relevant information for the end user.  Why was my request denied? What do I do next? What do I need to know about the resource?

The trick to making these work is the Append Disclaimer Text Rule Action, which will then allow some basic HTML to be entered.  This will get appended to the response message from the Booking Attendant (below the canned information that Exchange adds).  One caveat is that due to the way Exchange and Outlook utilize embedded special messages for Calendar Response Emails, most HTML is stripped.  Therefore the disclaimer text should only use very simple HTML tags like <FONT>, <B>, <BR>, etc. Most notably Tables and CSS will be stripped. However, if all your users are using OWA instead of desktop Outlook, quite full featured HTML is allowed. YMMV.

Putting it all Together

  1. Modify all of your Resource Mailboxes to remove any Add Additional Text settings under the Resource Information tab.
  2. Create a new Transport Rule under Organization Configuration/Hub Transport.  One rule for each type of response is necessary.  i.e. "Room Booking Accepted" and "Room Booking Denied for Permissions" or "Room Booking Conflict"
  3. For the Condition of the rule, choose the From People and When the Subject Field or Message Body Contains specific words.  Be sure NOT to choose the text patterns option, as this will not work for calendar responses.
  4. Click on these new rule conditions in the bottom pane and select each of the Resource Mailboxes in the From settings.  Then, in the subject or body selection, type the exact phrase that is part of the appropriate built-in Exchange meeting response.  For example, "your request was accepted" (no quotes)
  5. Click next, then choose Append disclaimer text and fallback to action if unable to apply for the Action.  Click in the bottom pane on append and enter the raw HTML for your response.  It is best to create and test the HTML elsewhere, than paste it into the box as there is no sort of preview or editor.
  6. For the rest of the settings of the Transport Rule accept the defaults.  Finish and close the rule.
  7. The responses should work within about 30 seconds of creating or modifying the rule
  8. Repeat as necessary for different resource types and responses. 

Note, this works equally well for Office 365/Exchange 2013/Online, but obviously the steps are slightly different through Exchange Admin Center.  An additional item to keep in mind is that it is unfortunately not possible remove the embedded canned response text that Exchange always includes. We refer to this as the "above the line" text, as exchange puts a horizontal rule and "Sent by Microsoft Exchange Server..."

This method has been of tremendous value to many of our clients to get much more useful responses, and happier staff.

Need help configuring this in your environment? Is your Exchange server out of control?  Contact us today!

Well Played Microsoft, Well Played

by Ed Sparks

April Fools Day seems to be on an upswing of increasingly clever and complex hoaxes the last few years, and Microsoft was no exception for 2015. 

Beautifully skewering their own naming practices, and particularly Apple's over-the-top design videos, Microsoft released MS-DOS Mobile.  

Today Microsoft launches MS-DOS Mobile, a new OS designed especially for Lumia smartphones.
Microsoft is going back to where productivity started for millions of people, launching a beautifully simple OS.

Today Microsoft launch MS-DOS Mobile, a new OS designed especially for Lumia smartphones. Microsoft are going back to where productivity started for millions of people, launching a beautifully simple OS. The MS-DOS Mobile preview is an essential download for those who remember life before Windows, those who want to go back to BASIC, or even those looking to boot into DOS for the first time.

“Turning our back on graphics was hugely liberating. We’ve dropped the resolution, and in doing so re-discovered our roots.”

The best part of this?  You can actually download and run this thing!  Set Blaster=A220! Oh the memories.


Not to be outdone, the Mountain View folks launched com.google.

Try it yourself.    !desirprus eb thgim ouY

Fixing Windows 10 Build 10041 Not Showing in Windows Update

by Ed Sparks

After a long 55 days Microsoft has finally released a major update to the Technical Preview of Windows 10.  In typical fashion they rambled on about how they're changing their build process, and going to release the product this summer, and how wonderful everything was going to be now as we users would be getting builds fast and furiously.

Then reality set in, and for a vast swath of users the much awaited build was nowhere to be found on Windows Update.  Refreshing Windows Update like a mad man had no effect.  It's not lost on everyone how Microsoft can't even seem to get downloading Windows right these days.  <face palm>

A busy thread has quickly emerged on the Microsoft Answers site, and for the majority of troublesome systems, the fix appears to boil down to a few items:

  • Make sure you are using drivers from your system vendor.  The most troublesome items seem to be Intel HD Graphics and Networking.  If you're using Microsoft's or Intel's published non-hardware-specific drivers, often this is causing systems to get locked in a Windows Update loop trying to download and install bad drivers over and over.  This blocks the next build from coming down, as it appears to want a pristine Windows Update status before starting.  So, go uninstall any drivers and re-install the versions from your hardware maker's site.  I'm looking at you Lenovo and HP owners.  
     
  • THEN, once you've checked, updated and rebooted...
    Download this hotfix from the Microsoft Update Catalog.  Make sure you put on your rose colored glasses and go back to 1998 first though.  You need to do this from Internet Explorer and install an Active-X Control.  Then add the 32 or 64 bit hotfix to your "basket".  Then download the basket.  Then right click on the downloaded file and Run As Administrator.  You know, because they couldn't just publish a link to this.
     
  • Alternatively, check/update the registry as follows:
Open regedit.exe
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability
BranchName, REG_SZ, fbl_impressive
ThresholdOptedin, REG_DWORD, 1
ThresholdRiskLevel, REG_SZ, low

Delete all other values

Once complete go to Settings App - Update & recovery - Windows Update
Tap or click Check for updates

  • Other users are reporting that disabling Windows Defender then rebooting sometimes fixes
     
  • Still others are going to the Settings App - Update & Recovery - Windows Update - Advanced Options and toggling to the Slow Ring (under Choose How Preview Builds are Installed) then reboot, then toggle back to the Fast Ring, then Tap or click Check for update

Good luck and happy testing!


Resource Mailbox Responses Show in Plain Text

by Ed Sparks

Here's another non-obvious gem that seems to have been slipping through the Exchange Team cracks for years now.

On Exchange 2010 if a Resource Mailbox (typically a meeting room) is set to send "Additional Text" in the "Resource Information" settings, the response will always arrive as Plain Text, even if it is configured with proper HTML.  However, this will only occur for users who are using Outlook 2010 or 2013 in online mode, rather than the preferred and standard cached mode.

This is a known issue with no current resolution.  It does not appear to affect Exchange 20103.

Additionally, due to the way this Resource Information text is wrapped in a special embedded calender response message, the formatting is VERY limited and non-standard; most HTML will not work correctly. It does, whoever, appear to work correctly with most HTML for users who receive the response via Outlook Web App (OWA).  Horribly inconsistent and frustrating.


Fix Event 513 CAPI2 Errors During Windows Backup

by Ed Sparks

Update: March 2016.
Commenters have noted this same fix appears to work correctly on Windows 10 as well


A semi-common error seen on various Windows 8.1 and 2012/R2 systems is the following during the start of system backups that use VSS (i.e. most backups).  This often causes the backup process to hang for a long period of time, or fail.

Application Event Log:
Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.

Details:
AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol.

System Error:
Access is denied.

Much digging through forums has found what appears to be the cause.

During backup a VSS process running under NETWORK_SERVICE account calls cryptcatsvc!CSystemWriter::AddLegacyDriverFiles(), which enumerates all the drivers records in Service Control Manager database and tries opening each one of them. , The function fails on MSLLDP record with "Access Denied" error.

Turned out it fails because MSLLDP driver's security permissions do not allow NETWORK_SERVICE to access the driver record.

What causes this to have incorrect permissions in the first place is unclear, but a fairly simple fix exists.  We've tested this on several systems without issue, but your mileage may vary.

It can be fixed by correcting the Security Description on the MSLLDP service, using the built-in command line utility SC.exe

Open an Administrative Command Prompt (NOT PowerShell) and execute the following.  This must all be one long command without carriage returns

sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

You should receive a successful result of

[SC] SetServiceObjectSecurity SUCCESS

If so, the problem is resolved, and there's no reboot required.  The next backup should complete successfully.

SharePoint 2013 Active Directory Import will NEVER delete users

by Ed Sparks

<face palm>

Microsoft teased us all with the prospect of finally having a simple, supportable and consistent way to quickly sync basic user information from Active Directory into SharePoint 2013.

No more do we have to deal with the wonders of FIM and this mess.  One-click wonder.

Look: it even filters disabled accounts with a checkbox!

It appears there's one minor problem...it doesn't work.

First off, check out Microsoft's (not so) tiny list of caveats/exceptions for AD Import.  

Consider the following situations and note what the AD import option does not support when you determine whether to use this option.  

Consider, indeed!  That should more accurately read: "If you wish to use this for any task whatsoever, choose a different option"

Well, it technically it does work, but I guess when they named it Active Directory Import they literally meant that. Once it imports a user it's there for the rest of eternity, never to be removed in any sort of automated fashion.  It doesn't matter if you disable, move, or delete an AD account - AD Import could care less, and will do nothing with the related SharePoint User Profile.  The "bdeleted" flag never gets updated.  Nothing.  Yes, Virginia, this wondrous tool will NEVER remove a disabled or deleted account.  Of course, the lack of deleted flags means we can't easily run PowerShell commands to remove orphaned users either.  In the eyes of the User Profile they're NOT orphaned.  They're still there as happy, safe and sound objects.

Honestly, Microsoft, do you ever test this stuff anymore?

It's our belief that this behavior comes from the fact that Active Directory Import appears to be based on a version of the DirSync utility to push users up to the Office 365 or Azure clouds, which also suffers from the same behavior (i.e. removing an on-premise user does nothing at all to the cloud user).

It also appears the LDAP filters may or may not even take effect either, nor are they documented about how they apply, or mix with the OU selection, etc.
This entire thing is just ridiculous and sad.

Back to User Profile Synchronization and FIM we go.

Here's a Microsoft Escalation Blog on this very issue.

 

Source: http://blogs.msdn.com/b/spses/archive/2015...