I have a client site running our Windows desktop software on a number of computers with 64 bit Office 365.
On most of their computers, our software is able to send email via Outlook.
However, two of their computers were upgraded to 365 last year (by their IT technician, not us), and both fail when they attempt to send email from our software.
Outlook works fine on its own, and so does our software - on both of these computers. But these two both can't send email from our software. (The other computers, which send email fine, are running exactly the same version of our software.)
When sending email, our software first checks for the existence of "Outlook.Application" or "Outlook.Application.*" keys in the Windows Registry to determine whether Outlook is installed. If not found, our program logic assumes that Outlook isn't installed, and attempts to use MAPI instead to send mail through another email client like Thunderbird (or through Outlook using MAPI). However, these computers both then crashed, because MAPI doesn't work on 64bit computers.
When I investigated these two problem computers, I found that they both had no "Outlook.Application" or "Outlook.Application.16" keys anywhere in their Windows Registry. I have never encountered this before. How and why would Office 365 install without creating these Registry entries? (I had just installed Office 365 on two computers here in my office, and they both had these keys and worked perfectly. And we have never encountered this before, at any of our other user sites.)
I discussed this with their IT technician. He did a complete uninstall of Office 365, and installed them from scratch, using the "on-line" install (that I had used on my computers - I sent him the URL to be sure). However, after this they were still unable to send email. When I investigated, I found that the Registry keys were still missing.
Their IT technician then asked me to export all the "Outlook.Application" and "Outlook.Application.16" keys in "Computer\HKEY_CLASSES_ROOT" and send them to him. He imported these on both those computers, but it did not fix the problem.
However, because the keys now existed, our software then attempted to send email directly through Outlook, using OLE. However it crashed on the line where it tried to create an Outlook Application Object:
loApp = CreateObject("Outlook.Application.16")
I built a special version with some extra test code in it. After failing to run the above line, it tried to run a line:
loApp = CreateObject("Outlook.Application")
This also failed - presumably because some Outlook application components have not been installed.
I did some fairly extensive Google searches for posts that might identify a solution, but found nothing that seemed to fit. A couple of posts suggested running an Office "Repair" from the installation tool.
I mentioned this to their technician, and he did this. Interestingly, when I then checked (using RegEdit), it had created a lot more "Outlook.Application" and "Outlook.Application.16" Registry keys. But our software still fails on both the "CreateObject" lines in that test version, and single "CreateObject" line in the normal version.
Both their technician and I are completely mystified (and now out of our depth in the Microsoft black arts of Office 365 installation and Windows).
Has anyone encountered this scenario before, and / or can suggest where we might go from here?
OK, the original post was getting a bit long, and I didn't want to clutter it with too much information. So here is some further info:
In answer to Eugene's questions:
Using RegEdit, I searched the entire Registry - for one of the
computers that didn't work, and one that did (plus my own here,
which also worked fine).
Their technician installed the latest 64 bit 365. If I understand
correctly, the initial install was done from an ISO file. When that
didn't work, he tried again using the "on line" install (which I had
successfully used here). He used the "on line" install again for the "repair". I don't have current build numbers, but could obtain these later in the week if relevant. But they should be up-to-date.
No we can't reproduce the problem ourselves in-house, and have never
seen it before at any other client site.
The site is running the same antivirus software on all computers (those
that work, and those that don't). So I suspect that this won't be
the cause.
Registry keys that match perfectly on those two computers are:
Computer\HKEY_CLASSES_ROOT\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_CLASSES_ROOT\Outlook.Application
Computer\HKEY_CLASSES_ROOT\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Backup\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\InprocServer32
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\RegisteredApplications
Something that may be significant:
The Windows Registry on the computer that does not work has four extra keys (that are not in the computer that does work):
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
That computer (which doesn't work) also has a folder C:\ProgramData\Packages\Microsoft.Office.Desktop.Outlook_8wekyb3d8bbwe\ with 3 subfolders in it (with system generated names):
The first (created in 2019) has a subfolder "\SystemAppData" which is
empty.
The other two (both with same date/time in early 2020) are completely
empty (i.e. have no SystemAppData subfolder)
I wonder whether these keys may somehow be causing mischief. Early next week the technician and I plan to back up these keys, and then delete them.
Does anyone know what these keys are about?
(I found a blog that may be relevant: https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/ But then again, it may not be.)
Keep in mind that older version of Windows Store Outlook ran in a sandbox and was not externally accessible. Uninstall it and reinstall again from the store - you will get a regular C2R version.
Eureka!!! Deleting those extra legacy Registry keys did the trick.
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Our software immediately was able to create Outlook Application objects, and send email via Outlook.
It seems that these extra keys dated back to an earlier attempted install by the client (before their current technician became involved). There were about 20 or so other 'Outlook*' keys in that part of the Registry with '8wekyb3d8bbwe' in their name. I subsequently deleted these too - on the the assumption that they were all legacy garbage. (As a rule, it is pretty dangerous to delete things you don't understand - but so far, so good. Although I am too chicken to delete a host of others in that location for Access, Excel, PowerPoint, Word with with '8wekyb3d8bbwe' in their name too.)
I had the same problem; it came from a brand-new computer!
What worked for me was the early binding. Select: Tools > Reference > Microsoft Outlook 16 object library.
Dim objOL As Outlook.Application
Set objOL = New Outlook.Application
Set objOL = Nothing
At the end, setting objOL to Nothing is crucial, otherwise the instance stays open, and it causes problems with Outlook.
Reference.
Here is my situation. I have emails on an old computer that are not anymore on the SMTP server but are stored locally on the computer. That computer is running Outlook 2011.
I have a new computer where I installed Outlook 2016. I don't want to import everything from old to new computer in order to start fresh. So I synced my accounts on the new computer. But all the old emails I don't have access to.
In order to recover them, I followed this: https://www.macworld.com/article/1156045/web-apps/export-outlook-2011.html
which worked great except that now all the emails I am adding have today's received date. Even though in the .eml files, it is clearly mentioned the real received date.
Any idea on how to do ?
Thank you!
Within our network infrastructure we utilize a 2007 Exchange Server for our domain.
Today I was faced with a situation where a user who has MS Office 2010 x64 and utilized Outlook 2010 called me and stated that her "Saved Items" inbox was missing. I remoted into her system and sure enough one of her mailboxes was not present.
It's easy enough to "fix" this by just adding the data file again which is located on a network share F:..\mailxxx.pst
This user has multiple mailboxes as a way to view her archived data.
Located in this shared folder there are additional .pst files that remained accessible to the user.
This appears to happen randomly and has happened at least one other time to this same user, and one time to a separate user who also has data on this same share.
Thoughts?
Microsoft does not support PST files on a network drive. This is a recipe for a disaster.
I have been trying to get the WEDU tool to work for Embedded Compact 7 and I'm having no luck.
https://social.msdn.microsoft.com/Forums/en-US/4cba2503-eb2a-410b-8429-5c63e226dad8/where-to-find-windows-embedded-ce-70-updates?forum=winembnatapp
Looking at this form, I've followed the instructions. When I get to the registration part, the form comes up and I click Continue, but it never gets me registered. I'm sent to a page with a whole bunch of download links. Has Microsoft broken this registration process?
It used to be that if you didn't agree to the question
Do you agree that a Windows Embedded representative may contact you using the phone number or email address provided by you to supply further Windows Embedded Information
then registration would fail, and you would be sent back to the initial page.
In order to find out what the default email client is, I found the same information over and over again: Look at the default string in HKLM\Software\Clients\Mail. (see for example this related question)
However, this seems not to be true for all OSs and/or situations:
I have two machines running Win7 64bit, let's call them A and B.
A has Outlook 2010 64bit and Thunderbird 3 32bit installed.
B has Outlook 2007 32bit and Thunderbird 3 32bit installed.
Both A and B have Thunderbird set as their default mail client.
However, the state of the registry is not as I expected it:
On machine A, both HKLM\Software\Clients\Mail and HKLM\Software\Wow6432Node\Clients\Mail have an empty string as the default string value.
On B, both those keys contain Microsoft Outlook as the default string value, which is clearly wrong.
Further investigation revealed that the correct value seems to be written to HKCU\Software\Clients\Mail on both machines.
I want my application to handle this correctly for all cases. It makes kinda sense, that Win7 now seems to hold a separate default mail client for each user, but it appears rather inconsistent. When looking at the plethora of information that points to HKLM\Software\Clients\Mail, it seems obvious that previous versions of Windows handled this differently and always wrote to that location. So when did this change? Has the wrong value on machine B any meaning? If not, why does it get written there in the first place? Does the mix of 64bit and 32bit email clients on the same computer change anything?
I would most appreciate if anyone would share reliable information or documentation that explains this topic! Maybe there is a Win32 API function that returns the correct value?
Does this MSDN article help you?
How to Register an Internet Browser or E-mail Client With the Windows Start Menu
Registrations made in the HKEY_CURRENT_USER subtree have higher precedence for the console user than corresponding registrations made in the HKEY_LOCAL_MACHINE. For new users on the system, the settings stored in HKEY_LOCAL_MACHINE are used.
For Windows XP a special article: How to modify the default Web browser and e-mail client programmatically in Windows XP and How to implement a per-user default mail client in Windows XP?
Sorry, can't help you with the Win32 API.
For Windows 10, this seems to be different - see the discussion here: https://superuser.com/q/1045349/176339
Quoting the relevant paragraph for your question, from papo's answer:
Registry entries for mailto protocol are under HKLM\SOFTWARE\Classes\mailto and as it is with other Classes, they could be overridden by entries for CURRENT_USER, under HKCU\SOFTWARE\Classes\mailto
BUT
There were changes in recent Windows versions and now, there are more places in registry which will further override shell associations from Classes. Moreover, in case of mailto they are mandatory and so rendering the Classes values for mailto useless.
Next in line of importance is Key:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\mailto]
which in turn is overridden by:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Roaming\OpenWith\UrlAssociations\mailto]
which is also used only if it's not overridden by:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto]
GOOD JOB Microsoft :)
Values under these Keys have the same format, a Key UserChoice with a ProgId valuename pointing to shell association Key from Classes.
But you can all but forget about editing these values, as there also is the Hash value. It's a protection against such registry edits.
User MUST click himself at least once to select an App on a standard Windows Open With dialog popup, if he also check the Always option, the Hash value is generated and the choice is remembered and written to last two Keys from the list above. Another option is to use the Settings as shown in the picture above.
It's a safeguard against malicious Apps, viruses and bad programmed Apps.
To troubleshoot a problem with default mailto association, you can delete mailto Keys from under all of these locations, except LOCAL_MACHINE.
Windows will re-create them on next use of the mailto protocol.