We have an In-house executable which creates Outlook Meetings and Appointments in shared calendars.
One user is having a problem creating appointments in a shared calendar using this code. This code's been running fine for years now.
WHAT HAS BEEN TRIED:
I had the user access the Calendar directly through Outlook. She was able to create meetings in the Shared Calendar without a problem.
EXCEPTION THROWN:
"The operation failed because of a registry or installation problem. Restart Outlook and try again. If the problem persists, reinstall."
Re-installing Outlook would be a major inconvenience for the user.
I'm wondering.
What area in the Registry would I look at?
Would recreating the .PST file be a reasonable alternative?
Can I use Outlook Redemption to troubleshoot the user's account?
It seems your Outlook profile (or Outlook installation itself) is corrupted. You can take a look at the Windows event log what else Outlook states about the error incident. At this stage, it is not clear whether it is related to the profile corruption (to re-create a pst) or Outlook itself.
Redemption is a wrapper around Extended MAPI (a low-level API on which Outlook is built on). But it doesn't provide any self-diagnostic services, only convenient access to the low-level functions. However, you can use Redemption for getting your job done without Outlook involved.
I'd suggest opening a support case with Microsoft if you need to continue working with OOM.
It turns out that it was a data issue.
I asked the user to create Appointments for other shared calendars using our custom executable. She was able to do so without a problem.
The exception message that I posted came from the call to GetSharedDefaultFolder
The Recipient parameter was created using an email address that doesn't exist on our Exchange server. That bad email address came from our database.
Related
I am building an Outlook Add-in that is using the Outlook mailitem property deferredDeliveryTime in order to postpone the sending of the message. Everything works fine but I have realized that if I send an email using deferedDeliveryTime and the application is closed it won't send the email until the application is reopened which defeats the purpose of the add-in. I am using Exchange/Office 365 and should therefore be able to push the message to the messaging queue and then close the application but I don't know how to do this.
One solution I have found is disabling the "Use Cached Exchange Mode to download email to an Outlook data file" in Account Settings. When disabled it sends the message immediately to the Exchange server but I need this setting to be enabled due to group policy.
I believe it should be possible to have it enabled while still being able to immediately send to Exchange. Do anyone know how/if this works? Or if there is some workaround.
You are on the right avenue, Outlook add-ins work only when the host application is launched. When you deal with a cached mode of connecting to the Exchange server your data is kept locally until Outlook synchronizes its folders. The non-cached mode works a bit different - the data is reflected from the server-side and no cache is preserved locally, your changes are reflected on the server-side almost immediately. It seems you have found a possible workaround already.
But you may also consider using EWS when Outlook is closed at any point of time, see Explore the EWS Managed API, EWS, and web services in Exchange for more information. For Office365 accounts you may take a look at MS Graph.
I have not tried that particular scenario, but you should be able to create a message in the online mode and send it in that mode. On the Extended MAPI (C++ or Delphi only) level, you can open the parent folder (e.g., Outbox) with the MAPI_NO_CACHE flag, create the message (IMAPIFolder::CreateMessage), populate its properties, and send it (IMessage::SubmitMesage) - since the parent folder is opened in the online mode, the newly created message will also be in the online mode.
If Extended MAPI is not an option, you can try to use Redemption (I am its author, any language) - it will let you open a folder in the online mode (RDOSession.GetFolderFromID(..., MAPI_NO_CACHE | MAPI_BEST_ACCESS)).
Open browser
Navigate to http://www.windowsazure.com/en-us/
Select portal top right
login with my email address
Receive the below error
https://manage.windowsazure.com/Error/Login?getsupport=true&f=255&MSPPError=-2147217320
Receive the error
" We are having trouble logging you into the portal
Please contact Customer Service for assistance."
Using IE or Chrome, incognito or not, cookies cleared or not, cache cleared or not. The problem still exists. Also tried on multiple devices media centre PC, desktop running windows 7, iPhone 5, ipad 3...
Prior to November 2012 I have accessed the windows azure subscription without a problem.
I clicked the customer service link and the australian number is 13 20 58 I have contacted that number explaining that I cannot access my windows azure subscription and each time I login I receive an error. They proceed to redirect me to other support teams where I repeat my details and the problem they either redirect me again or provide a number to call.
In one case I was redirected to a number that no longer exists. Another I was told to raise a case on the windows azure portal page the same portal page that I receive an error on when logging in, when I asked for alternative options there were none.
So far I've spoke with the msdn support team, windows subscription support, online services, etc and still no resolution. In the latest call to support they have said to raise the issue on the forums so here goes.
Anyways long story short I have probably spent 3+ hours calling Microsoft support explaining the problem, waiting on hold, being redirect, repeating... still I can't access my windows azure subscription
I checked in commerce.microsoft.com and there is a windows azure subscription associated with my email address
Subscription-1
Windows Azure MSDN - Visual Studio Premium
Does anyone have any suggestions on how to resolve this issue?
Some time it's happened wait for while and retry
or just ask azure support in twitter
Editing for those who are like me and skipped reading the comments (in small font) below the OP's question. This was resolved and was due to the first reason I list below. However, it could (and has) happen in past for other reasons as well, so might as well keep this response here in case it helps someone else out.
Try logging at https://portal.azure.com/
The manage.windowsazure.com isn't even DNS resolvable to any website - I am not sure how you are getting that address (maybe its from some part of Azure IAM pipeline that hasn't been updated) and (more interestingly) how you are able to open that link - Maybe this is something available only in your region ! (but I am stretching here).
Regardless, I also tried to find other instances of similar issues and in general I see this issue is related to cases when the an account has been transitioned to Office 365.
Here an account was moved and resulted in creation of two accounts with different passwords - solution here was to set the Office 365 account (new account) as a co-admin on the old account that was used to setup the Azure account.
Here the account was not provisioned correctly in Azure AD Store and had to be removed and re-created using DirSync
Here, the problem seems to be related to (the new) Account Provisioning in Azure AD.
In general, it seems this is a problem that might be harder to explain to level 1 support. You might have better mileage speaking to your organizations IT admin and have them check for any inconsistencies that might be similar to those stated above.
Try forcing the directory in the URL like so
https://portal.azure.com/#domain.name
For example in case of MS AAD domain
https://portal.azure.com/#mycompany.onmicrosoft.com
In case of custom domain
https://portal.azure.com/#mycompany.com
Sometimes there is some odd behaviour with redirect loops or when you no longer have access to the tenant but you have selected 'last visited' in the Startup directory.
Glad to hear this was resolved by support. Since this was posted, we made a number of updates to the login process and types of accounts (incl. the addition of MFA). At TechEd we announced a new portal (video # http://channel9.msdn.com/Blogs/Windows-Azure/Azure-Preview-portal) if you want to see what is coming.
I have a business LS web application which I update from time to time.
I do the update by simply using the deploy wizard and everything is working great.
My problem is handling all my users that opened my system in their IE and left it open through my deploy process.
Since they have the old web application is opened on their browsers, and I have deployed the new version to the server, I can see errors occuring in certain situations.
Is there a way to make sure all users with the application opened will be forced to refresh the web application page? Maybe remotely disconnect all currently connected users?
There is no built in way of doing this. You will need to write a custom solution. Someone in the MSDN Forums has written a class to do this for OOB apps.
You should be able to reuse the timer part of that class. I'm not sure if the UpdateAvailable method will work for Web-based applications or not. You'll have to experiment with that.
Alternatively, you can create a custom notification system. Insert a message to your users into a table in your database from the administrator account. Have a timer on the user account check the table every so often. If it finds a new message, display a notification to the user.
Then you can use either an HTTP Response Header or an ASP method to log the users out as described in this Microsoft Support article.
I've a scenario wherein I need to send/assign tasks from my browser UI to the concerned. This should happen with Outlook being offline (or for that matter outlook not even configured on the terminal) so that the user can be accessing a workflow from any terminal (using his/her AD credentials) and if required should have the ability to send a task to the concerned without having to return to his own terminal to be able to do so.
I envision that the user's credentials should be used to look up the AD for his/her email ID and send a task using the same from anywhere in the intranet.
Using Outlook object library I have been able to assign/send tasks, but with the Outlook being fired up and not otherwise.
Redemption does the sync of contacts while Outlook is offline but not tasks.
Kindly help if anybody has had a chance to do something similar.
Thanks in advance.
Redemption could help you here as you can run it it on a web server which will connect to you exchange env via mapi for you.
There are other ways dependant on you version of exchange EWS or Exchange DAV.
EWS comes with a managed API now a days to take some of the sting out of it.
There are similar 3rd party libraries for Exchange DAV as well.
They all contain contact and directory lookups.
I'm looking to write an automated monitor script to programmatically retrieve information from another user's Exchange 2003 inbox. I have working C++ code to log into MAPI and connect to my own inbox. I can also use the Control Panel->Mail applet to configure another user's mailbox into my profile, and my code can access that way. However, this was done on my desktop with Outlook installed, which provides a richer mail profile editor.
Since this will run on a server, I'd prefer not to install Outlook at all. Instead, I can install the MAPI client. I then create a simple MAPI app that pops up the mail profile wizard using MAPILogonEx() with the MAPI_LOGON_UI flag. However, the basic MAPI client doesn't have the features to configure another user's mailbox. As a requirement, I can only run this script as the service account of the monitoring application, so I cannot tell it to run as the account whose mailbox I want.
Is it still possible to connect to another user's mailbox (assuming permissions are already granted) using the basic MAPI client? Or is it absolutely necessary to install Outlook for this functionality?
I would strongly recommend using the Microsoft Exchange MAPI Client (as you have linked). It is engineered to be far more robust than the Outlook version of these libraries. You should find the API no different between Outlook and Exchange Server with respect to Extended MAPI.
You will need to use Extended MAPI (as described by Cain T S Random) to open other mail stores, and of course your application will need to be logged in as the Windows user with appropriate permissions on the Exchange server.
I see... I'm not sure how to do that explicitly; that's usually a side effect of calling CreateStoreEntryID with the wrong flags. What's you're looking to do is probably:
Get an IID_IExchangeManageStore from your default message store
Call CreateStoreEntryID
Then open that store by the entry ID
LPEXCHANGEMANAGESTORE mapiObject = NULL;
store->QueryInterface( IID_IExchangeManageStore, (LPVOID *) &mapiObject);
mapiObject->CreateStoreEntryID( server, mailbox, OPENSTORE_TAKE_OWNERSHIP |
OPENSTORE_USE_ADMIN_PRIVILEGE, &len, &buffer);
//Call OpenEntry on the entry id
If you want a more detailed example, search the source of the MFC MAPI project for CreateStoreEntryID. If you have other questions, the best place to get them answered is the microsoft.public.win32.programmer.messaging newsgroup.
Have you looked into ConfigureMsgService? I believe that works with Exchange MAPI, or are you saying you tried that and it didn't work?