Troubleshooting Persistent Reappearing Meetings in Exchange + Arctera Integration
We've been running into a really annoying issue lately in our Exchange environment, which is integrated with Arctera, and I'm hoping someone here might have seen something similar or have some insights. The problem is that some users are experiencing old or deleted calendar meetings reappearing in their Outlook calendars. They decline them, delete them properly (even emptying Deleted Items), but days or weeks later, the same meeting invite can pop back up. It's causing significant calendar clutter and confusion. Initially, we were looking into potential sync issues related specifically to the Exchange-Arctera integration, wondering if maybe updates weren't propagating correctly or if there was some conflict in how shared calendar resources are handled between the two systems. We're still investigating that angle. However, while digging deeper into the Exchange side of things, I stumbled across a pretty comprehensive article that outlines several Exchange-specific reasons why this might happen, independent of any integration. It covers things like: Lingering invites in different mail folders. Corrupt recurring meeting series. Issues with calendar delegation permissions. The Calendar Repair Assistant (CRA) potentially misbehaving. Outdated clients or mobile device sync problems. Here's the article if anyone's interested: How to Stop Exchange Server from Recreating Meetings? It has some useful steps for both end-users and admins (like PowerShell commands to check/disable CRA or repair mailboxes). My question for this group is: Has anyone using an Exchange + Arctera setup encountered this specific "ghost meeting" issue? If you did, did you find the root cause was purely within Exchange (like one of the points in the article), or did you discover an interaction or configuration nuance related to the Arctera integration that was contributing to it? We're particularly curious if certain sync settings or how delegate access is managed across both platforms might play a role. Any shared experiences or troubleshooting tips specifically within the Exchange/Arctera context would be hugely appreciated! Thanks in advance,
Ready; No idle devices are available
I'm new to Symantec Backup Exec as I've taken over the duties of someone else that left the company. The problem that I'm having is I can't get Backup Exec to backup anything, not to tape, not to a shared drive, etc.. Logically I would have thought the issue was that the previous employee had used his account for all Symantec functions, I was able to change his account information for all the services and the connection to the server. Everything appears to be fine, I'm able to do a Test Run without any problems but when I go to do a backup I don't receive any alerts I just get a message that says "Ready; No Idle devices are available". Same result no matter where I try to backup to. Anyone seen this before, have any suggestions of how I can fix it? We're using Backup Exec 2012 S1a. Thanks
BE 2012 - After migration, storage pools but no storage devices
Migrated our BE 2012 server using the steps in the article below. We moved from a Win2K8 R2 Enterprise OS to Win2K8 R2 Standard OS for licensing reasons. Everything seemed to migrate successfully except for the storage devices which are simply network drives/shares. In the BE console on the new BE server, the storage pools, that were on the old BE server, are there and the properties of the storage pools show the related storage devices. The problem is that the storage devices do not show up as individual devices on the storage tab of the BE console, so I cannot edit the properties or even use them with the migrated backup jobs. I tried renaming the old BE server and taking it offline, then renaming the new BE server to the old BE server name, but I could not log into BE using the old or new name after that. I put the new name back into place so now I'm back at square one again. I thought about just configuring new storage devices with new names but I'm concerned about how that will affect my ability to restore existing backed up data that is on these drives. Ideally, I would like to get some help on how I can get this migrated BE server to recognize the storage devices again. https://support.symantec.com/en_US/article.TECH129826.html Thank You, RABacking up Active Directory: V-79-57344-33928 - (AD LDS) database was not found.
Hello, We have this error from time to time, but it usually fixes itself without any end user intervention. However I am getting this error three nights in a row now on one of our domain controllers. This started happening on Wed morning, and continued through Friday morning. In all three instances the error message in the log is: Job ended: Thursday, October 29, 2009 at 1:18:54 AM Completed status: Failed Final error: 0xe0008488 - Access is denied. Final error category: Security Errors For additional information regarding this error refer to link V-79-57344-33928 Errors Click an error below to locate it in the job log Backup- \\dc1.domain.com\System?State V-79-57344-33928 - Unable to complete the operation for the selected resource using the specified options. The Active Directory, Active Directory Application Mode (ADAM) or Active Directory Lightweight Directory Services (AD LDS) database was not found. So I checked the selections and under the server in question, I can see System State > Active Directory > C:_WINDOWS_NTDS, and this is all checked off. I did a test Resource Credentials for everything in this backup and it all returned successful so I'm at a loss. Under Settings > Microsoft Active Directory for this job properties we have all three boxes checked (GRC, Consistency Check, Continue if Consistency check fails.) Backup method is greyed out, but says Full - Back up entire Active Directory. We are using Symantec Backup Exec 12.5 for Windows Servers Media Server Version 12.5 Rev 2213 Administration Console 12.5 Rev 2213 Desktop and Laptop Option: Version 3.1 Rev. 3.41.32a Installed updates: Service Pack 2 Hotfixes: 324947 317436 325647 319242 324012 326004 323894 324011 Thanks for the help, we really do appreciate it!
