I'm getting mailbox exception for quite some time now, not even once was the streaming subscription made successfully since the last month.
Exception:
Can't connect to the mailbox of user Mailbox database guid: 67f43d90-xxxx-xxxx-xxxx-7a296a993f38 because the ExchangePrincipal object contains outdated information. The mailbox may have been moved recently.
My code to create subscription:
private void CreateSubscription()
{
var events = new List<EventType>
{
EventType.NewMail,
EventType.Created,
EventType.Deleted,
EventType.Modified,
EventType.Moved,
EventType.Copied,
EventType.FreeBusyChanged
};
if (_subscription != null)
{
((StreamingSubscription)_subscription).Unsubscribe();
_connection.RemoveSubscription((StreamingSubscription)_subscription);
}
_subscription = _exchange.SubscribeToStreamingNotifications(subscriptionFolders, events.ToArray());
_connection.AddSubscription((StreamingSubscription)_subscription);
if (stopwatch.IsRunning)
{
stopwatch.Restart();
var e = stopwatch.ElapsedMilliseconds;
logger.LogFatal($"Stopwatch restarted: {e}");
}
else
{
stopwatch.Start();
var e = stopwatch.ElapsedMilliseconds;
logger.LogFatal($"Stopwatch started: {e}");
}
}
The exception occurs at the following line:
_subscription = _exchange.SubscribeToStreamingNotifications(subscriptionFolders, events.ToArray());
Stacktrace:
Microsoft.Exchange.WebServices.Data.ServiceResponseException: The specified object was not found in the store., Can't connect to the mailbox of user Mailbox database guid: 67f43d90-xxxx-xxxx-xxxx-7a296a993f38 because the ExchangePrincipal object contains outdated information. The mailbox may have been moved recently.
at Microsoft.Exchange.WebServices.Data.ServiceResponse.InternalThrowIfNecessary()
at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
at Microsoft.Exchange.WebServices.Data.ExchangeService.SubscribeToStreamingNotifications(IEnumerable`1 folderIds, EventType[] eventTypes)
at Mach.Omega.EwsClient.WinService.Classes.ExchangeServiceClient.CreateSubscription() in D:\Sourcecode\Mach.Omega\Sourcecode\Mach.Omega.EwsClient.WinService\Mach.Omega.EwsClient.WinService\Classes\ExchangeServiceClient.cs:line 172
at Mach.Omega.EwsClient.WinService.Classes.ExchangeServiceClient.CreateSubscription(IEnumerable`1 subscriptionFolders) in D:\Sourcecode\Mach.Omega\Sourcecode\Mach.Omega.EwsClient.WinService\Mach.Omega.EwsClient.WinService\Classes\ExchangeServiceClient.cs:line 131
at Mach.Omega.EwsClient.WinService.Classes.SubcriptionProcess.Subscribe() in D:\Sourcecode\Mach.Omega\Sourcecode\Mach.Omega.EwsClient.WinService\Mach.Omega.EwsClient.WinService\Classes\SubcriptionProcess.cs:line 154
at Mach.Omega.EwsClient.WinService.EwsService.SubscriptionWorker() in D:\Sourcecode\Mach.Omega\Sourcecode\Mach.Omega.EwsClient.WinService\Mach.Omega.EwsClient.WinService\EwsService.cs:line 200
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
Please note that I am able to fetch emails from the mailbox just fine, but cannot create the streaming subscription.
Is this OnPrem or Office365 ? as a generally rule you should always use the X-AnchorMailbox header https://blogs.msdn.microsoft.com/webdav_101/2018/06/16/best-practices-important-and-critical-headers-for-ews/, that error indicates a routing issue or stale directory information (potentially caused by replication issues in AD). If its Office365 try the MailboxGUID as the X-AnchorMailbox https://developer.microsoft.com/en-us/office/blogs/error-improvement-for-invalid-x-anchormailbox-in-rest-api-calls/
Related
When an account is closed (on-chain), the account.subscribe listener try to decode the account, and it throws an error. How can I handle the error, to execute a callback when the error happens. It's an expected event.
Currently, I'm getting: "Error: Invalid account discriminator". Probably because the account doesn't exist anymore.
The account.subscribe method uses Solana Web3's onAccountChange and EventEmitter.
The account.subscribe listener decodes the account whenever an update for it is received:
const account = this._coder.accounts.decode(this._idlAccount.name, acc.data);
If the account is deleted, then it will fail to decode as the expected type. It looks like the code you linked could use a PR to fix this behavior!
In other places, it returns null if the account data is incorrect, so perhaps the event emitter should return null if the account fails to decode.
In the meantime, you can implement your own version of this which adds that check, ie:
const listener = this._provider.connection.onAccountChange(
address,
(acc) => {
if (acc == null) {
ee.emit("change", null);
} else {
const account = this._coder.accounts.decode(
this._idlAccount.name,
acc.data
);
ee.emit("change", account);
}
},
commitment
);
I am using below code in the button event, so that user can send mail through self machine outlook directly (nuget Microsoft. Office. Interop.Outlook). Code is working when I am debugging below code in my localhost and send mail from outlook. But problem is when I deployed the code into web server and browse through IE from my work station, mail not send through outlook.
This error message show in log:
Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
How can I resolve this issue?
Web application reside into web server and users will access the application from IE and then they will send mail through self machine outlook.
public void SendEmailOutlook(string mailToRecipients, string mailCCRecipients, string subjectLine, [Optional] string attachments, string HTMLBody)
{
try
{
Microsoft.Office.Interop.Outlook.Application oApp = new Microsoft.Office.Interop.Outlook.Application();
Microsoft.Office.Interop.Outlook.MailItem oMsg = oApp.CreateItem(Microsoft.Office.Interop.Outlook.OlItemType.olMailItem);
Outlook.Recipients oRecips = oMsg.Recipients;
List<string> oTORecip = new List<string>();
List<string> oCCRecip = new List<string>();
var ToRecip = mailToRecipients.Split(',');
var CCRecip = mailCCRecipients.Split(',');
foreach (string ToRecipient in ToRecip)
{
oTORecip.Add(ToRecipient);
}
foreach (string CCRecipient in CCRecip)
{
oCCRecip.Add(CCRecipient);
}
foreach (string to in oTORecip)
{
Outlook.Recipient oTORecipt = oRecips.Add(to);
oTORecipt.Type = (int)Outlook.OlMailRecipientType.olTo;
oTORecipt.Resolve();
}
foreach (string cc in oCCRecip)
{
Outlook.Recipient oCCRecipt = oRecips.Add(cc);
oCCRecipt.Type = (int)Outlook.OlMailRecipientType.olCC;
oCCRecipt.Resolve();
}
oMsg.Subject = subjectLine;
if (attachments.Length > 0)
{
string sDisplayName = "MyAttachment";
int iPosition = 1;
int iAttachType = (int)Outlook.OlAttachmentType.olByValue;
var Sendattachments = attachments.Split(',');
foreach (var attachment in Sendattachments)
{
Outlook.Attachment oAttach = oMsg.Attachments.Add(attachment, iAttachType, iPosition, sDisplayName);
}
}
if (HTMLBody.Length > 0)
{
oMsg.HTMLBody = HTMLBody;
}
oMsg.Save();
oMsg.Send();
oTORecip = null;
oCCRecip = null;
oMsg = null;
oApp = null;
}
catch (Exception e)
{
//print(e.Message);
}
}
Outlook, just like every other Office app, cannot be used from a service (such as IIS).
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
As a possible workaround you may consider using EWS or any other REST API (for example, Graph API) if you deal with Exchange server profiles only. See Explore the EWS Managed API, EWS, and web services in Exchange for more information.
I've had this issue too."Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))."
Server environment：Windows server 2019&iis
Local machine：Windows 10&iis
Tip:The Microsoft office doesn't support that use OutWork IIS or Asp.net
So,I give you right answer(It's worked):
1、Run "win+R" ,then inuput 'Dcomcnfg'
2、As this pic:
enter image description here
We had some code that has been working for the past 10 months (since it was developed) and just stopped working this afternoon. It's a WebAPI code to send a channel message mentioning the bot and a user, which now is returning "Bad Request. Invalid request body was sent."
If the "Mentions" property is not provided, the call works, and the message is sent without the #mentions. So, I wonder if there was a breaking change in this API that's now expecting a different format for the "Mentions" property.
It's quite simple to reproduce by following the example code found in the Microsoft Graph documentation.
I'm posting here in the hope some fellow dev spots something obvious or is aware of an alternative way of using the API that it might stop complaining, as Microsoft takes forever to reply.
Here's the code we have that can lead me to discover the issue:
private async Task SendMentionToTheBotAsync(GraphServiceClient onBehalfOfClient, string userName, string teamId, string channelId)
{
var supportAgentUser = await onBehalfOfClient.Me.Request().GetAsync();
var chatMessage = new ChatMessage
{
Body = new ItemBody
{
ContentType = BodyType.Html,
Content = $"<at id=\"0\">{Configuration["BotName"]}</at>: This is the start of the conversation between {userName} and <at id=\"1\">{supportAgentUser.DisplayName}</at>."
},
Mentions = new List<ChatMessageMention>
{
new ChatMessageMention
{
Id = 0,
MentionText = Configuration["BotName"],
Mentioned = new IdentitySet
{
Application = new Identity
{
DisplayName = Configuration["BotName"],
Id = Configuration["BotAppId"],
AdditionalData = new Dictionary<string,object>
{
{
"applicationIdentityType", "bot"
}
}
}
}
},
new ChatMessageMention
{
Id = 1,
MentionText = supportAgentUser.DisplayName,
Mentioned = new IdentitySet
{
User = new Identity
{
DisplayName = supportAgentUser.DisplayName,
Id = supportAgentUser.Id,
AdditionalData = new Dictionary<string,object>
{
{
"userIdentityType", "aadUser"
}
}
}
}
}
}
};
await onBehalfOfClient.Teams[teamId].Channels[channelId].Messages
.Request()
.AddAsync(chatMessage);
}
Microsoft Support responded with :
"Thank you for contacting Microsoft Support.
I understand the issue is related to the post messages to Teams. Based on the screenshot, it seems you are using mention to a channel. It's possible that you are using key "conversationIdentityType#odata.type" in your request.
Could you please try to remove "conversationIdentityType#odata.type" key from the request body and try again. It should work. It is because deployment is on the way in the Asia region. Once it's 100% rolled out, this key WILL NOT be entertained in the request."
Removed the key and it worked for me.
Paulo,
Unfortunately i am not a programmer. I am using Graph calls in a Microsoft 365 Power Automate workflow. I have an app that i use to get the Authorisation Bearer token and then post to Teams messages using a graph HTTP action.
Here is the syntax of the HTTP ( purple items are variables if u r not familiar with Flow )
click to view image of Power Automate workflow HTTP action
For a lot of customers, we connect to the Office 365 Outlook IMAP server, and that works just fine. However, for one customer now it does not work. I can log into portal.office.com with the username and password, and go to Outlook there and see the mailbox, but I can't for the life of me get this to work in my code. This is my code:
var stream = new MemoryStream();
var logger = new ProtocolLogger(stream, false);
using (var client = new MailKit.Net.Imap.ImapClient(logger))
{
try
{
client.Connect("outlook.office365.com", 993, true);
client.AuthenticationMechanisms.Remove("XOAUTH2");
client.Authenticate(#"SVC_CubitDLE#lyse.no", #".whb----%RS*,H^");
var inbox = client.Inbox;
inbox.Open(FolderAccess.ReadWrite);
var uids = await inbox.SearchAsync(SearchQuery.NotSeen);
} catch (Exception exc){
exc.Dump();
stream.Position = 0;
var reader = new StreamReader(stream);
reader.ReadToEnd().Dump();
}
}
I tried with and without the line client.AuthenticationMechanisms.Remove("XOAUTH2");.
The exception thrown is AuthenticationException with message LOGIN failed.
The log emitted in the steam is:
S: * OK The Microsoft Exchange IMAP4 service is ready. [UABSADAAUAAyADYANABDAEEAMAAxADkAOAAuAEYAUgBBAFAAMgA2ADQALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]
C: E00000000 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+
S: E00000000 OK CAPABILITY completed.
C: E00000001 AUTHENTICATE PLAIN AFNWQ19DdWJpAAAAAAAAAAAAAAAAAAAASF4=
S: E00000001 NO AUTHENTICATE failed.
C: E00000002 LOGIN SVC_CubitDLE#lyse.no ".whb----%RS*,H^"
S: E00000002 NO LOGIN failed.
Any idea to what I'm doing wrong here?
It is very possible that IMAP is disabled for that user. I would check to see if that's enable if you have access to the AD.
Here's an article
I am using
I am logged into a remote server for accessing Visual studio as well as MS CRM. I have taken sample code from SDK and trying to run the code:
CrmAuthenticationToken token = new CrmAuthenticationToken();
token.AuthenticationType = 0;
token.OrganizationName = "AdventureWorksCycle";
CrmService service = new CrmService();
service.Url= "http://10.16.16.205:5555/mscrmservices/2007/crmservice.asmx";
service.CrmAuthenticationTokenValue = token;
service.Credentials = new System.Net.NetworkCredential"username", "password", "domain");
// Create the account object.
account account = new account();
// Set the properties of the account object.
account.name = "Fourth Coffee123";
account.address1_line1 = "29 Market St.";
account.address1_city = "Sam";
account.address1_stateorprovince = "MT1";
account.address1_postalcode = "9999";
account.donotbulkemail = new CrmBoolean();
account.donotbulkemail.Value = true;
// Create the target object for the request.
TargetCreateAccount target = new TargetCreateAccount();
// Set the properties of the target object.
target.Account = account;
// Create the request object.
CreateRequest create = new CreateRequest();
// Set the properties of the request object.
create.Target = target;
// Execute the request.
CreateResponse created = (CreateResponse)service.Execute(create);
I am using Crm Web Service for this, but Its throwing exception:
Exception Details:
System.Net.WebException: The request
failed with HTTP status 401:
Unauthorized.
Source Error:
Line 114: [return: System.Xml.Serialization.XmlElementAttribute("Response")]
Line 115: public Response Execute(Request Request) {
Line 116: ***object[] results = this.Invoke("Execute", new object[]* {**
Line 117: Request});
Line 118: return ((Response)(results[0]));
One thing you are missing is a real username and password. I am assuming that you have omitted this for the purposes of this question.
Have you checked the security role on the user that you are using for the web service call? Add this user to the System Administrator role if you haven't already.
With CRM often times, this error has nothing to do with security but something else altogether.
First turn on CRM tracing and look there. This will give you more error detail. Here's how:
http://support.microsoft.com/kb/907490
Also you can try to use my exception formatter to get more detail on the error. This is an extension class that will allow you to format the exception and print it to stdout or to the http response. Find it here:
http://paste.ly/5Y66
Use it this way:
try {
// do all your stuff
} catch (Exception ex) {
ex.Print();
}
Notice that in the formatted exception output, you can see the "Details" property deserialized such that you can see the text version. This is where CRM hides the real exception most of the time.