After my Zarafa (Small Business) update to version 7.1.7 all emails were lost. The accounts are still there.
What can I do to solve the problem quickly?
From which version did you upgrade? What do the Zarafa logs say, specifically /var/log/zarafa/server.log (or if you configured syslog instead, what does that log say)?
Related
I know I should probably ask MS about this, but I dont know if I trust their communication tools to get me a satisfying answer.
I have recently taken the task to test an application of mine.
Part of this test is to send an e-mail to it, then log in and see if I get the result I want (this is automated)
For this the process is:
Open Outlook -> Send Mail
Close Outlook
Open App -> Check result
Open Outlook -> Send Mail
Close Outlook
But for some reason, every second time the outlook app is opened, (including manually opening the app to check on configurations etc.) Mails will go to the outbox but will not be sent, unless I manually trigger them to.
Now, there are possible solutions like keeping the app running continously, or telling my testing-suite to press F9 after every sent mail, but I want to tackle the root cause, and fix the underlying problem.
The Outlook Version used is the latest Version of Office 365 Outlook.
Has anyone else had this experience and figured out a fix?
Thank you in advance.
Keep in mind that message submission is an asynchronous process, so if you close Outlook while it is still sending, the message might end up stuck in the Outbox.
You can call Namespace.SendAndReceive to force submission, but it is still asynchronous. You can hook into the SyncObject.SyncEnd event on the first (All Accounts) SyncObject from the Namespace.SyncObjects collection and quite only after that event fires.
Since this problem occured on a machine I do not own, I tried avoiding certain easy troubleshooting steps. After I couldnt find an answer on my own, and I didnt get responses here that would've helped me solve this without a wooden hammer method, I asked for permission to issue a repair to the local office 365 suite.
After the repair it had redownloaded and installed the entirety of office 365.
After connecting my company MS account to outlook, the issue no longer appeared.
I guess this counts as solving this issue.
I'm currently experiencing something rather weird: while migrating emails from a GoDaddy email server to a new G Suite set up for a number of users, I was able to successfully move for a couple of emails, as confirmed by Google's 'Complete' tick beside them. I was able to observe the migration too as it went on.
However, for one of the emails, the number of emails read just seems to keep increasing, and it still hasn't displayed 'Complete', but remains stuck on '99%'.
See screenshots I literally took just now below: as of the first latest screenshot, it says 'Successfully migrated 3230 emails', while stuck on 99%:
Then I hit refresh, check the status of that same account, and now it says '...3250 emails', while still stuck on 99%:
This isn't how it's supposed to behave, at least that isn't the behaviour I experienced with the previous 4 emails in that list. Ideally, it should say 'Migrating X out of fixed_amount emails'. In this case, that fixed_amount was
about 2,000 emails. It has now since passed that figure, but instead of showing 'Complete', it instead shows 'Successfully migrated new_amount' where new_amount keeps increasing.
This has been ongoing for almost 24 hours now. Honestly, I don't know if this is a bug or not. I really just need some helpful info to know if I should be concerned or not, perhaps maybe if someone else has run into this. Anyone?
Stumbled on to Google's documentation: https://support.google.com/a/answer/7032598?hl=en
To quote the 'Why does my migration look like it's stuck at 99%?' section:
You’ll see 99% when all email is migrated. After everything is
migrated, the data migration service applies any labels to the
migrated email, which can take time. When the labels are applied, you
should see that the migration is complete (100%).
You might also see this issue if the estimated number of emails to
migrate exceeds the actual number of messages. The migration will
report 99% until the migration completes. This process might take some
time.
You shouldn't be concerned. I was migrating around 29.000 emails from a personal gmail to Google Workspace gmail and the migration took 4 days (migrating only one user), from which the last 1.5 days the migration was "stuck" at 99%. No need to restart the migration, eventually it indeed finishes. I also got several error codes (e.g. 17009 - 'Generating an access token with the supplied credentials was unsuccessful...'), but none proved valid, I haven't actioned on them as, like in your case, I saw the number of migrated emails increasing.
After some googling I found that this reason if caused by too many scheduled conferences by my Application Endpoint. My only problem is, how do I delete/remove currently stored scheduled conferences for my application endpoint, when the only access I have to my server is through PowerShell??
EDIT:
Just found a command that actually could increase number of scheduled meetings per organizer (Set-CsUserServicesConfiguration -MaxScheduledMeetingsPerOrganizer 2000), but it didn't change the issue. I'm still receiving MaxConferencesExceeded error. Any ideas??
Use Get-CsUserServicesConfiguration to make sure the change has actually occurred, and/or setting it globally to make sure it has the correct context for your users.
I've also found with a large pool, it can take a while to kick in.
Have you tried republishing your Lync topology after making the change? A bit dramatic, but can help with Lync gets itself into a knot with changes.
I have roughly 9,000 undelivered messages in my mail spool in Coldfusion 9. As far as I can tell the only way to manage these messages is to manipulate them 10 at a time through the CF Admin GUI.
I'm looking for a way to expedite this process. I'd like to just clear the queue, or batch send them all.
Does anyone know how to do this?
Thank you,
-Dave
Go into the filesystem and move the files from cfusion/mail/undelivr to cfusion/mail/spool. Simple!
Take a look at Ray Camden's SpoolMail (http://spoolmail.riaforge.org/). This is a very handy plug-in that you can add to all your servers and at bulk move your emails to spool and resend them.
Someone sent me a snippet at some point that would try to reprocess the queue periodically at some point, but for the life of me, I can;t find it or see it on google. - sorry.
HOWEVER: the undeliverable queue is just a bunch of files, you can write yourself a little application that will try to reprocess the queue periodically and prune out the ones that have been in the undeliverable too long.
I am pretty sure that the spool only tries to deliver mail once
just move the files back into the spool directory to have the spooler "retry"
you would have to keep a file or DB to track what has been tried & how many times.
I would also send a notification on what has been deleted - or at least log it.
-sean
PS> 9000? what is your traffic like? I would suspect there is a problem if you have that many undeliverables....
You should write simple CF program for tracking and deleting for undelivered mails.
Use cfdirectory tag.
If you moved your mail server and the spool doesn't seem to ever empty out, you need to open up each .cfmail file and change the IP number. I moved my mail server as well, and when I brought it back up I had forgotten to change the IP setting for mail in CF Admin, and wound up with 21,000 emails in my spool by the next day. Ugh. I could have run a cf script on it to open up each one, change the IP number, and then move the file into the spool dir, but opted instead of downloading a free search and replace utility from download dot com. Worked like a charm. It took about twenty minutes to do the full s&r and then a few seconds to move them all over.
The file system is the simplest way.
To attempt to resend the emails, move the files in ~\ColdFusion2016\cfusion\Mail\Undelivr to ~\ColdFusion2016\cfusion\Mail\Spool.
If you just don't care about those email files then simply delete them.
I point my development mail server to point to nowhere (smtp.gmail.com.dontSend) so no mail goes out and they all just stack up in undelivered. That way the rest of my development team does not get all the errors I generate and catch through email. More importantly, no test emails accidentally go out to real accounts.
I go into the CF-Administrator to look at and manage my undelivered mail when testing but if/when it gets huge I just delete them from the file system.
I have an ASP MVC 2 application, through which I occasionally send emails using SmtpClient.Send(). Typically, emails are sent out in batches of between 1 and 50 emails, with hours or even days passing between batches. I have this all set up so that the emails are actually sending just fine. But, the problem is that when the emails are sent, my site suddenly becomes unavailable for about 15 minutes, and I have no idea why.
My site is hosted on a shared, Windows 2008 server with a third-party web host.
Here is the relevant section in my web.config file, edited for privacy:
<system.net>
<mailSettings>
<smtp deliveryMethod="Network" from="fromemail#doman.com">
<network host="mail.DOMAIN.COM" userName="username" password="password"/>
</smtp>
</mailSettings>
</system.net>
Does anyone have any thoughts or ideas as to why this might be happening? I've been trying to reaserch it and Google it for some time now, but I'm just not coming up with anything.
This really could be many different things but..
The first thing I suggest you do is enable ASP.NET Health Monitoring on your site. This should hopefully help you gain visibility of the exception that is causing this issue (A guide to using Health Monitoring).
For obvious reasons be sure not to choose the Mail Provider to send you your exceptions - perhaps use the SQL provider or write a custom provider that writes to a file.
I would also ask your hosts to look into the Event Log for any information that may be of value.
Hope that helps.
E-mail can be an expensive operation. Have you considered using the asynchronous e-mail send so that the process does not block your main thread?