From Cork to Toronto

 A couple of solutions which are off the well beaten track: 1. You are in a hybrid environment with an on-premises mailbox but an E3/E5 license applied to your user. Exchange Online spontaneously creates a mailbox. (Workaround for this is to remove the Exchange Online sublicence along with the licenses which depend on it - you just have to remember you did that when you migrate to EXO down the road...) 2. You have an old group policy or settings reg file which you think is aligned with MS365 norms but contains the following key - delete it, or change it to Delete in the Group Policy Preferences if it is a wider issue. Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Exchange DWORD MapiHttpDisabled 1 https://learn.microsoft.com/en-us/outlook/troubleshoot/connectivity/outlook-not-connect-exchange-use-mapi-over-http

 I wanted to import .Net Framework 4.8 into my WSUS (for Server 2016) and ran into some obstacles. Edge was default but wasn't adding the basket to import. Internet Explorer had the basket but claimed my version of WSUS was incompatible. The solution was based on this post -  enable "Allow Sites to be reloaded in Internet Explorer Mode" in Edge settings restart Edge add the URLs below (and remove any others) https://catalog.update.microsoft.com/ https://catalog.update.microsoft.com/v7/site/Home.aspx  Returning to WSUS and choosing "Import Updates" allowed the import.  There is a banner which invites opening in Edge mode (and breaking it again) but it's not like we can expect Microsoft to recognise its own incompatible websites, or properly HTML5-ize WSUS Catalog so I just ignored it. At least they did, apparently , fix Group Policy's HTML Export. This is a rare need for me so the "Allow for 30 days" option was sufficient for what I needed to a...

We were trying out a new imaging process and could not add iManage FileSite to a new user's Outlook 365 32-bit v1808 using ADDIMAN (or manually via Data File Management). This is an Outlook error rather than one specific to iManage. Fortunately we found an on-point forum post which pointed towards a missing C:\Program Files (x86)\Common Files\System\MSMAPI\1033\MAPISVC.INF - copying this file (and grandparent folder as far back as MSMAPI) from a known-good machine cleared the problem.

This afternoon I helped someone recover an unsaved document from an .ASD file after a crash which did not trigger the usual file recovery pane. While the File/Options/Save dialog pointed to %appdata%\Microsoft\Word , File, Open, Recent, Recover Unsaved Documents points to %localappdata%\Microsoft\Office\UnsavedFiles After copying the .ASD file into the latter (UnsavedFiles) folder, I was able to successfully open the .ASD file, save it to a DOCX and turn it over to the person I was helping. The person I was helping was using Word 2010 but I had the .ASD emailed to me, and did the recovery in Office 365 v1904, as I didn't have control of their machine.

Had a laptop come in where it would appear to boot normally, but at the logon screen both internal and external keyboards and mice did not respond. In Windows Repair, everything worked fine, just not within the operating system itself. The machine had a locally managed encrypted SSD which I wanted to decrypt before reimaging it, and there were some other items which would be more easily remediated if I could get 1-2 working login sessions before dropping the hammer on it. It did have working networking, so I gathered info via Event Viewer and established that I had access to the admin share and could control the machine via psexec. Using psexec to start SFC did not resolve the issue, nor did CBS.log point me in the right direction. The Event Viewer log for System noted a bunch of driver start events (Application Popup Event ID 26, Kernel-PnP Event ID 219) including for mouhid.sys. The "hid" rang a bell as being related to Human Interface Device, so it seemed like I migh...

So DDP|ST has been out of support for a bit and obviously hardware encryption has taken a bit of a knock lately, but some of you may be stuck with some Windows 7/OPAL setups for the time being so I'll write this up. The scenario was that DDP|ST was installed into an image - target machine was a Dell Latitude E7470 with a LiteON SED SSD. Everything was ticking along in the usual way until ready to hit "Encrypt" on the SED. On doing so... nothing happens. The Encrypt button is greyed but it is possible to back out of the section or close the UI entirely. I remembered overnight that I had seen this before - it required uninstalling and reinstalling the DDP|ST (including the usual PITA manual uninstall order, preserving Authentication data when asked, requiring reinstatement of the preboot text notices and removing undesired authentication methods). The log files for DDP|ST are in \ProgramData\dell\Dell Data Protection\ but as yet I haven't figured out a cause. Of cou...