Exchange 删除默认数据库报错

系统:Windows Server 2008 R2

环境:Exchange 2010 SP1

域:Windows Server 2008R2

我以为是这样的,Exchange 2010 系统邮箱数据库删除方法如下:

1、迁移普通用户,将所有用户迁移到新建的数据库中。

Get-Mailbox -database "邮箱数据库名称"  | New-MoveRequest -TargetDatabase 目标邮箱数据库名称

2、迁移系统仲裁邮箱

Get-Mailbox -database "邮箱数据库名称" –Arbitration | New-MoveRequest -TargetDatabase 目标数据库名称

3、删除默认邮箱数据库

打开EMC→组织设置→邮箱(右击删除)

4、删除EDB 数据文件

事实上,是这样的:

在迁移完所有邮箱后(包括3个仲裁邮箱),还是无法删除该邮箱数据库。

系统报错如下:

有一个或多个活动的导入请求连接在该邮箱数据库上。只有清除这些活动的连接,删除操作才能继续。

ERRO:"this mailbox database is associated with one or more active MailboxImport requests. To get a list of all MailboxImport requests associated with this database..."

经过和管理员聊天,结合系统报错提示。初步判断问题原因:终端用户通过Outlook 导入本地PST文件后,系统保留了该导入请求并且仍有未完成的导入请求。

排错步骤:

要查询系统导入/导出记录,需要该账号是:系统导入/导出组的成员。

1、        默认是没有这个组的,我们需要新建这个导入导出组,成员为:administrator

具体命令如下:

New-ManagementRoleAssignment -Name "Import Export_Domain Admins" -            User "administrator" -Role "Mailbox Import Export"

2、        查询导入/导出请求:

Get-MailboxImportRequest | ft -au

3、        清除所有导入/导出请求(可以看到上面有2种类型的导入请求:Completed 、Failed )

Get-MailboxImportRequest -Status Completed | Remove-MailboxImportRequest(清除完成的导入请求)

Get-MailboxImportRequest -Status Failed | Remove-MailboxImportRequest(清除失败的导入请求)

4、        删除默认邮箱数据库

至此,问题解决。回家吃饭咯~~~

实践证明,目前搜索Windows有关问题时,使用bing 搜索比百度靠谱!

时间: 2024-11-09 05:00:50

Exchange 删除默认数据库报错的相关文章

删除Exchange2010数据库报错“此邮箱数据库与一个或多个活动 MailboxExport 队列关联”

Exchange2010控制台删除数据库时报错"此邮箱数据库与一个或多个活动 MailboxExport 队列关联",我判断系统内有未处理或处理失败的命令,使用命令 Get-MailboxExportRequest -Status faild 查询数据库内导出请求是否有处理失败的命令, 使用命令Get-MailboxExportRequest -Status faild | Remove-MailboxExportRequest 删除邮件系统内失败的导出请求,后先在Exchange控制

oracle 11g 手动删除表空间文件导致数据库报错处理方法

简单说下原因:当时图方便没进数据库,直接在datafile目录下删除了表空间对应的数据文件 导致后来数据库报错,并且不能删除表空间 错误如下:ORA-01116:error in opening database ****ORA-01110:data file 54:'/home3/datafile/arrange/NewArrange.dbf'ORA-27041:unable to open fileLinux Error:2: No Such file or directoryAdditio

修改mysql存储引擎备份数据库报错及解决方案

备份数据库报错 原因:由于监控服务器最近cpu负载比较高.(cpu4核心,负载2.7左右)感觉很奇怪,因为别的服务器mysql占用的资源并不多,因此我首先优化了数据库的配置文件.cpu稍微下降了一点,但是没有特别明显的变化. 于是,从mysql的存储引擎和日志考虑,结果发现默认用的引擎是myisam.好吧.换成innodb,(由于事先我没备份,就在配置文件修改了引擎,因为日志除了二进制其他并没有开启.所以没动它.重启数据库. ok 早就听说这两个引擎,区别,看来性能差别真大啊! 好吧.备份数据库

由于删除DBF文件报错 —— ORA-01033: ORACLE initialization or shutdown in progress

由于移动或删除DBF文件报错:ORA-01033: ORACLE initialization or shutdown in progress 原因:一般该类故障通常是由于移动文件而影响了数据库日志文件出现损坏而导致的无法正常进行IO操作而引起的错误.ORACLE将识别为数据库未装载完成而导致出现如上错误. 故障特征:使用命令行sqlplus或PL/SQL Developer均无法打开数据库.但是可以使用sys用户以sysdba的身份登录系统 解决方法: 1. 在 ‘开始’-->‘运行’执行cm

附加数据库报错:无法打开物理文件 XXX.mdf",操作系统错误 5:"5(拒绝访问。)"

今天在附加数据库的时候出现如图报错信息: 无法打开物理文件 XXX.mdf",操作系统错误 5:"5(拒绝访问.)"错信息如图:(是不是远程服务器数据库附加出现只读那个情况,也可以这样解决??,经测试,是这样的,不过远的用户是user,改成完全控制允许) 首先,我的数据库安装根目录和附加的数据库不是同一个目录,在安装数据库的时候根目录是默认的,为C盘下的目录,而我要附加的数据库的目录为E盘下,所以:解决方案一:使用windows账户登进,将被附加的数据库移植到根目录下,如图:

MySql 插入数据库报错 Incorrect string value: '\xF0\xA0\x86\xA2'

今天从nginx日志分析搜索关键字,然后把关键字插入到Mysql数据库里,出现如下错误 SQL state [HY000]; error code [1366]; Incorrect string value: '\xF0\xA0\x86\xA2' for column 'XXXX' at row 38; nested exception is java.sql.SQLException: Incorrect string value: '\xF0\xA0\x86\xA2' for column

Emoji表情符号录入MySQL数据库报错的解决方案

前言:手机app应用评论的时候,恢复表情符号,提示失败.?1,查看tomcat后台日志,核心报错信息如下:  Caused by: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x97\xF0\x9F...' for column 'CONTENT' at row 1at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1074)at com.mysql.

mysql 保存emoji时报,数据库报错:Caused by: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x82\xF0\x9F...' for column 'review' at row 1

错误原因:我们可以看到错误提示中的字符0xF0 0x9F 0x98 0x84 ,这对应UTF-8编码格式中的4字节编码(UTF-8编码规范).正常的汉字一般不会超过3个字节,为什么为出现4个字节呢?实际上是它对应的是智能手机输入法中的表情.那为什么会报错呢?因为mysql中的utf-8并不是真正意义上的utf-8,它只能存储1~3个字节长度的utf-8编码,如果想存储4个字节的必须用utf8mb4类型.不而要使用utf8mb4类型,首先要保证Mysql版本要不低于 MySQL 5.5.3. 常用

远程登录oracle 12.2数据库报错ORA-28040解决办法

今天新安装的oracle 12.2.0.1数据库,通过本地sqlplus远程登录12c数据库报错ora-28040,如下: ORA-28040: No matching authentication protocol 解决办法(亲测可行): 进入到$ORACLE_HOME/network/admin下,编辑sqlnet.ora文件(如果不存在,则创建一个,或者去samples目录下复制一份),在末尾添加下面一行,不需要重新启动数据库及监听,再次通过本地sqlplus访问远程12c数据库,登录成功