搜尋本站文章

2017-06-21

[SQL Server]:變更、移轉(ALTER AUTHORIZATION)全部資料庫的擁有者(database owner)為 sa


若資料庫擁有者(database owner)有問題時,將導致許多作業無法執行。
例如:
  • 建立複寫(Replication)機制
  • 建立資料庫圖表(Database diagram)
  • 建立 SQL CLR等作業失敗。

會發生資料庫擁有者有所異常,可能是:
  • 資料庫擁有者是屬於一個不存在、被停用的Windows使用者,例如:異機備份還原、但已刪除此Windows使用者。
  • 資料庫擁有者的權限問題。

可使用:ALTER AUTHORIZATION ON DATABASE 將資料庫擁有者變更移轉為 sa。

-- 產生變更全部的資料庫擁有者為 sa:ALTER AUTHORIZATION ON DATABASE
-- 但資料庫狀態必須是 ONLINE、不是 正在還原(RESTORING)、不是 唯讀(Read-Only)

SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];' 
FROM sys.databases
WHERE state =0 AND is_read_only= 0 AND name NOT IN ('master', 'model', 'tempdb', 'distribution');


系統資料庫的擁有者,依據預設值是 sa 帳戶。



範例:ALTER AUTHORIZATION ON DATABASE 將資料庫擁有者變更移轉為 sa

-- 01_查詢:全部資料庫的擁有者
USE master
GO
SELECT d.name N'資料庫', p.name N'資料庫擁有者', d.owner_sid N'安全性識別碼', is_read_only, state_desc
FROM sys.databases  d INNER JOIN sys.server_principals p
ON d.owner_sid = p.sid
-- WHERE state =0 AND is_read_only= 0 AND d.name NOT IN ('master', 'model', 'tempdb', 'distribution')
ORDER BY p.name;

/*
條件式說明:

state = 0:資料庫狀態是 ONLINE
is_read_only = 0:資料庫狀態不是唯讀

資料庫狀態必須是 ONLINE、不是 正在還原(RESTORING)、不是 唯讀(Read-Only)

name NOT IN ('master', 'model', 'tempdb', 'distribution'):避開系統資料庫
無法變更 master、model、tempdb 或 distribution 系統資料庫的擁有者
*/


-- 01_查詢:全部資料庫的擁有者



-- 02_產生變更全部的資料庫擁有者為 sa:ALTER AUTHORIZATION ON DATABASE
-- 但資料庫狀態必須是 ONLINE、不是 正在還原(RESTORING)、不是 唯讀(Read-Only)
SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];' 
FROM sys.databases
WHERE state =0 AND is_read_only= 0 AND name NOT IN ('master', 'model', 'tempdb', 'distribution');


-- 02_產生變更全部資料庫的擁有者為 sa:ALTER AUTHORIZATION ON DATABASE



-- 03_執行先前所產生的 ALTER AUTHORIZATION ON DATABASE 陳述式



-- 04_已經變更資料庫擁有者是 sa





相關範例

-- 01_變更全部資料庫(System, User)的擁有者為 sa
SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];' 
FROM sys.databases;


-- 02_變更全部使用者資料庫(User)的擁有者為 sa
- 不包含系統資料庫
SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];' 
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'tempdb', 'distribution');



無法變更資料庫(database owner)的擁有者為 sa

舉例來講:

  • 資料庫狀態為 唯讀(Read-Only)
  • 資料庫狀態為 正在還原(Restoring)
  • 無法變更 master、model、tempdb 或 distribution 系統資料庫的擁有者
  • 不存在的帳戶


(一) 若資料庫狀態為唯讀(Read-Only)

無法變更資料庫(database owner)的擁有者為 sa。
例如:
AlwaysOn 次要複本(Secondary Replica)資料庫、資料庫鏡像(Database Mirroring)的鏡像資料庫等。

錯誤訊息
訊息 3906,層級 16,狀態 1,行 1
無法更新資料庫 "DB1",因為資料庫是唯讀的。

-- 061_資料庫狀態為唯讀(Read-Only),無法變更資料庫(database owner)的擁有者為 sa



(二) 若資料庫狀態為正在還原(Restoring)

無法變更資料庫(database owner)的擁有者為 sa。 例如: 記錄傳送(Log Shipping)的次要資料庫(Secondary Database)

錯誤訊息
訊息 927,層級 14,狀態 2,行 3
資料庫 'DB9' 無法開啟。它目前正在還原當中。

-- 062_資料庫狀態為正在還原(Restoring),無法變更資料庫(database owner)的擁有者為 sa



(三) 無法變更 master、model、tempdb 或 distribution 系統資料庫的擁有者

錯誤訊息
訊息 15109,層級 16,狀態 1,行 3
無法變更 master、model、tempdb 或 distribution 資料庫的擁有者。


-- 063_無法變更 master、model、tempdb 或 distribution 系統資料庫的擁有者




(四) 不存在的帳戶

錯誤訊息
訊息 15151,層級 16,狀態 1,行 3
無法 尋找 主體 'sa1111',因為它不存在或您沒有權限。

-- 064_不存在的帳戶





將廢除的功能:sp_changedbowner

未來的 Microsoft SQL Server 版本將移除這項功能。
請避免在新的開發工作中使用這項功能,並規劃修改目前使用這項功能的應用程式。
請改用 ALTER AUTHORIZATION。

舊版 sp_changedbowner 範例:

-- 01_sp_changedbowner:變更全部資料庫(System, User)的擁有者為 sa
USE master
GO
EXEC sp_MSforeachdb 'USE ? EXEC sp_changedbowner ''sa'''
GO

-- 065_sp_changedbowner:變更全部資料庫(System, User)的擁有者為 sa





參考文件

ALTER AUTHORIZATION (Transact-SQL)
https://technet.microsoft.com/zh-tw/library/ms187359(v=sql.110).aspx

sp_changedbowner (Transact-SQL) -- 未來的 Microsoft SQL Server 版本將移除這項功能
https://technet.microsoft.com/zh-tw/library/ms178630(v=sql.110).aspx

2017-06-18

[SQL Server]:全部停用 (DISABLE) 資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)


因故需要全部停用 (DISABLE) 資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)。

停用 FOREIGN KEY 條件約束的效益

  1. 優化效能,經由停用 FOREIGN KEY 條件約束,讓新增、修改與刪除(INSERT、UPDATE、DELETE)資料的速度更快。
  2. 無須依據 PK、FK 順序來匯入資料


舉例來講,可應用於:測試用資料庫、快速匯入資料、複寫(Replication)機制訂閱者端(Subscriber)的資料庫等情境。

注意事項:
使用「ALTER TABLE tbname NOCHECK CONSTRAINT ALL」,將停用資料表上的 FOREIGN KEY 條件約束(CONSTRAINT) 與 CHECK 條件約束(CONSTRAINT)

可以使用以下 T-SQL 陳述式達成

-- 全部停用:資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)、CHECK 條件約束(CONSTRAINT)
USE UserDB
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? NOCHECK CONSTRAINT ALL"
GO

-- 全部啟用:資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)、CHECK 條件約束(CONSTRAINT)
-- 不檢查現有資料
USE UserDB
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
GO

示範環境:SQL Server 2016

無法利用 SSMS 觀察到 FOREIGN KEY 條件約束(CONSTRAINT) 是否被停用或啟用。



練習一:違反 FOREIGN KEY 條件約束,無法修改資料

示範如下

-- 練習一:違反 FOREIGN KEY 條件約束,無法修改資料

/*
主索引資料表:Region
外部索引資料表:Territories
使用 RegionID 作為外部索引資料行(Foreign Key Coumn)

Region 資料表的 RegionID 的值是:1、2、3、4。
*/

USE Northwind
GO

-- 00_查詢:資料庫內 FOREIGN KEY 條件約束(CONSTRAINT)的相關狀態
SELECT f.name N'物件名稱', is_disabled N'已停用(1)', is_not_trusted N'不檢查現有資料(1)',
 s.name N'結構描述', o.name N'外部索引資料表', 
 sc.name N'結構描述', r.name N'主索引資料表', delete_referential_action_desc N'在進行刪除時,宣告的參考動作之描述',
 update_referential_action_desc N'在進行更新時,宣告的參考動作之描述', f.type_desc N'物件描述'
FROM sys.foreign_keys f
 INNER JOIN sys.objects o ON f.parent_object_id = o.object_id
 INNER JOIN sys.schemas s ON o.schema_id = s.schema_id
 INNER JOIN sys.objects r ON f.referenced_object_id = r.object_id
 INNER JOIN sys.schemas sc ON r.schema_id = sc.schema_id
ORDER BY o.name
GO

-- 01_失敗:刻意更新為不存在 主索引資料表的 RegionID:100
-- 因為有 FOREIGN KEY 條件約束 的保護
UPDATE [dbo].[Territories]
SET RegionID =100
WHERE TerritoryID = 01581
GO

/*
錯誤訊息

訊息 547,層級 16,狀態 0,行 11
UPDATE 陳述式與 FOREIGN KEY 條件約束 "FK_Territories_Region" 衝突。
衝突發生在資料庫 "Northwind",資料表 "dbo.Region", column 'RegionID'。
陳述式已經結束。
*/

-- 001_查詢全部資料表的FOREIGN KEY 條件約束


-- 002_失敗:刻意更新為不存在 主索引資料表的 RegionID:100






練習二:因已停用 FOREIGN KEY 條件約束,測試資料可以寫入

示範如下


-- 01_全部停用:資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)、CHECK 條件約束(CONSTRAINT)
USE Northwind
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? NOCHECK CONSTRAINT ALL"
GO

-- 02_查詢:資料庫內 FOREIGN KEY 條件約束(CONSTRAINT)的相關狀態
SELECT f.name N'物件名稱', is_disabled N'已停用(1)', is_not_trusted N'不檢查現有資料(1)',
 s.name N'結構描述', o.name N'外部索引資料表', 
 sc.name N'結構描述', r.name N'主索引資料表', delete_referential_action_desc N'在進行刪除時,宣告的參考動作之描述',
 update_referential_action_desc N'在進行更新時,宣告的參考動作之描述', f.type_desc N'物件描述'
FROM sys.foreign_keys f
 INNER JOIN sys.objects o ON f.parent_object_id = o.object_id
 INNER JOIN sys.schemas s ON o.schema_id = s.schema_id
 INNER JOIN sys.objects r ON f.referenced_object_id = r.object_id
 INNER JOIN sys.schemas sc ON r.schema_id = sc.schema_id
ORDER BY o.name
GO

-- 03_成功:刻意更新為不存在 主索引資料表的 RegionID:100
-- 因為已經停用 FOREIGN KEY 條件約束

UPDATE [dbo].[Territories]
SET RegionID =100
WHERE TerritoryID = 01581
GO

-- 04_驗證:確認已經寫入違反 FOREIGN KEY 條件約束
SELECT TerritoryID, TerritoryDescription, RegionID FROM  [dbo].[Territories]
WHERE TerritoryID = 01581
GO

-- 05_全部啟用:資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)、CHECK 條件約束(CONSTRAINT)
-- 不檢查現有資料
USE Northwind
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
GO

-- 06_驗證:確認已經寫入違反 FOREIGN KEY 條件約束
SELECT TerritoryID, TerritoryDescription, RegionID FROM  [dbo].[Territories]
ORDER BY TerritoryID
GO

-- 013_全部停用:資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)、CHECK 條件約束(CONSTRAINT)



-- 014_已全部停用:資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)、CHECK 條件約束(CONSTRAINT)



-- 015_成功:刻意更新為不存在 主索引資料表的 RegionID:100



-- 016_驗證:確認已經寫入違反 FOREIGN KEY 條件約束



-- 017_全部啟用:資料庫內的 FOREIGN KEY 條件約束(CONSTRAINT)、CHECK 條件約束(CONSTRAINT)
-- 不檢查現有資料


-- 018_驗證:確認已經寫入違反 FOREIGN KEY 條件約束





SSMS 檢視資料表上的 FOREIGN KEY 條件約束

示範環境:SQL Server 2016

無法利用 SSMS 觀察到 FOREIGN KEY 條件約束(CONSTRAINT) 是否被停用或啟用。

-- 061_SSMS_ 觀察資料表_FK_PK



-- 062_SSMS_ 點選「關聯性」



-- 063_外部索引鍵關聯性



-- 064_FK_資料表及資料行規格



-- 065_FK_資料表和資料行



-- 066_停用FK_強制使用外部索引鍵條件約束



-- 067_變更FK屬性,需要異動參與的資料表



-- 068_無法識別,FK是否被停用



-- 069_資料庫關聯圖表_無法呈現是否被停用



-- 070_檢視_關聯性的屬性



-- 071_利用系統檢視觀察_FK已被停用





參考文件

[SQL Server]:全部停用 (DISABLE) 資料庫內的 CHECK 條件約束(CONSTRAINT)
http://sharedderrick.blogspot.tw/2017/06/sql-server-disable-check-constraint.html

[SQL Server]:全部停用 (DISABLE) 資料庫內的 DML 觸發程序(Trigger)
http://sharedderrick.blogspot.tw/2017/06/sql-server-disable-trigger.html

How to disable all triggers and constraints?
http://www.sqlusa.com/bestpractices2005/disabletriggerconstraint/

[SQL Server][Replication]:複寫使用者正在插入至 NOT FOR REPLICATION 識別欄位時...遭遇錯誤
http://sharedderrick.blogspot.tw/2017/06/sql-serverreplication-not-for.html

DISABLE TRIGGER (Transact-SQL)
https://msdn.microsoft.com/zh-tw/library/ms189748.aspx

停用(Disable)與啟用(Enable)「觸發程序(Trigger)」
http://sharedderrick.blogspot.tw/2010/09/disableenabletrigger.html

停用複寫的檢查條件約束
https://msdn.microsoft.com/zh-tw/library/ms190235.aspx

唯一條件約束與檢查條件約束
https://msdn.microsoft.com/zh-tw/library/ms187550.aspx#Check

2017-06-17

[SQL Server]:全部停用 (DISABLE) 資料庫內的 CHECK 條件約束(CONSTRAINT)


因故需要全部停用 (DISABLE) 資料庫內的 CHECK 條件約束(CONSTRAINT)

效益是優化效能,經由停用 CHECK 條件約束,可讓新增、修改(INSERT、UPDATE) 資料的速度更快。

舉例來講,可應用於:測試用資料庫、複寫(Replication)機制訂閱者端(Subscriber)的資料庫等。

可以使用以下 T-SQL 陳述式達成


-- 全部停用:資料庫內的 CHECK 條件約束(CHECK CONSTRAINT)
USE UserDB
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? NOCHECK CONSTRAINT ALL"
GO

-- 全部啟用:資料庫內的 CHECK 條件約束(CHECK CONSTRAINT)
-- 不檢查現有資料
USE AdventureWorks2014
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
GO

示範環境:SQL Server 2016

無法利用 SSMS 觀察到 CHECK 條件約束(CONSTRAINT) 是否被停用或啟用。



全部停用資料庫內的 CHECK 條件約束(CHECK CONSTRAINT)

示範如下

USE AdventureWorks2014
GO

-- 查詢:資料庫內的 CHECK 條件約束(CHECK CONSTRAINT)的相關狀態
SELECT s.name N'結構描述',o.name N'資料表', c.name N'CHECK 條件約束', 
 is_disabled N'已停用(1)', is_not_trusted N'不檢查現有資料(1)',
 definition N'T-SQL 運算式', c.type_desc N'物件類型描述', c.type N'物件類型'
FROM sys.check_constraints c
 INNER JOIN sys.objects o ON c.parent_object_id = o.object_id
 INNER JOIN sys.schemas s ON o.schema_id = s.schema_id
ORDER BY s.name
GO

-- 全部停用:資料庫內的 CHECK 條件約束(CHECK CONSTRAINT)
USE AdventureWorks2014
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? NOCHECK CONSTRAINT ALL"
GO

-- 全部啟用:資料庫內的 CHECK 條件約束(CHECK CONSTRAINT)
-- 不檢查現有資料
USE AdventureWorks2014
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
GO


-- 001_資料庫內 CHECK 條件約束(CHECK CONSTRAINT)的相關狀態




-- 002_全部停用:資料庫內的 CHECK 條件約束(CHECK CONSTRAINT)



-- 003_已全部停用資料庫內的 CHECK 條件約束




-- 004_全部啟用:資料庫內的 CHECK 條件約束
-- 不檢查現有資料


-- 005_已全部啟用資料庫內的 CHECK 條件約束






SSMS 檢視資料表上的條件約束

無法利用 SSMS 觀察到 CHECK 條件約束(CONSTRAINT) 是否被停用或啟用。

-- 010_SSMS_查詢資料表上的條件約束



-- 011_SSMS_無法停用_CHECK_條件約束





參考文件

[SQL Server]:全部停用 (DISABLE) 資料庫內的 DML 觸發程序(Trigger)
http://sharedderrick.blogspot.tw/2017/06/sql-server-disable-trigger.html

How to disable all triggers and constraints?
http://www.sqlusa.com/bestpractices2005/disabletriggerconstraint/

[SQL Server][Replication]:複寫使用者正在插入至 NOT FOR REPLICATION 識別欄位時...遭遇錯誤
http://sharedderrick.blogspot.tw/2017/06/sql-serverreplication-not-for.html

DISABLE TRIGGER (Transact-SQL)
https://msdn.microsoft.com/zh-tw/library/ms189748.aspx

停用(Disable)與啟用(Enable)「觸發程序(Trigger)」
http://sharedderrick.blogspot.tw/2010/09/disableenabletrigger.html

停用複寫的檢查條件約束
https://msdn.microsoft.com/zh-tw/library/ms190235.aspx

唯一條件約束與檢查條件約束
https://msdn.microsoft.com/zh-tw/library/ms187550.aspx#Check

[SQL Server]:全部停用 (DISABLE) 資料庫內的 DML 觸發程序(Trigger)


因故需要 全部停用(DISABLE):資料庫內的 DML 觸發程序(Trigger)
停用範圍,包含:AFTER 觸發程序、INSTEAD OF 觸發程序

效益是優化效能,經由停用 DML 觸發程序(Trigger),讓新增、修改與刪除(INSERT、UPDATE、DELETE)資料的速度更快。

舉例來講,可應用於:測試用資料庫、複寫(Replication)機制訂閱者端(Subscriber)的資料庫等。

可以使用以下 T-SQL 陳述式達成

-- 全部停用:資料庫內的 DML 觸發程序(DML Trigger)
USE UserDB
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? DISABLE TRIGGER ALL"
GO


本範例是全部停用:資料庫內的 DML 觸發程序(Trigger),
包含:AFTER 觸發程序、INSTEAD OF 觸發程序




DML 觸發程序

當使用者試圖透過資料操作語言 (DML) 事件來修改資料時,便會執行 DML 觸發程序。
DML 事件包括資料表或檢視的 INSERT、UPDATE 或 DELETE 陳述式。

當引發任何有效的事件時,都會引發這些觸發程序,不論是否有任何資料表資料列受到影響




全部停用資料庫內的 DML 觸發程序(Trigger)

示範如下

USE AdventureWorks2014
GO

-- 01_查詢:資料庫內的 DML 觸發程序(DML Trigger)的相關狀態
SELECT s.name N'結構描述',o.name N'資料表', t.name N'觸發程序名稱', t.is_disabled  N'已停用(1)', 
 tEV.type_desc '引發觸發程序的每個事件', is_instead_of_trigger N'INSTEAD OF 觸發程序(1)', 
 t.type_desc N'物件類型的描述',  parent_class_desc N'觸發程序父類別的描述'
FROM sys.triggers t INNER JOIN sys.trigger_events tEV ON t.object_id = tEV.object_id
 INNER JOIN sys.objects o ON t.parent_id = o.object_id
 INNER JOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE parent_class_desc = 'OBJECT_OR_COLUMN' AND o.type='U'
ORDER BY s.name
GO

-- 全部停用:資料庫內的 DML 觸發程序(DML Trigger)
USE AdventureWorks2014
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? DISABLE TRIGGER ALL"
GO

-- 全部啟用:資料庫內的 DML 觸發程序(DML Trigger)
USE AdventureWorks2014
GO
EXEC sp_MSforeachtable @command1="ALTER TABLE ? ENABLE TRIGGER ALL"
GO

-- 001_查詢資料庫內的觸發程序



-- 002_全部停用:資料庫內的 DML 觸發程序(DML Trigger)



-- 003_查詢資料庫內的觸發程序_全部停用



-- 004_全部啟用:資料庫內的 DML 觸發程序(DML Trigger)



-- 005_全部啟用:資料庫內的 DML 觸發程序(DML Trigger)



-- 006_查詢資料庫內的觸發程序_全部啟用





SSMS 停用單一觸發程序

-- 010_SSMS_觸發程序已啟用




-- 012_可以停用觸發程序



-- 013_已停用此觸發程序



-- 014_可以啟用此觸發程序



-- 015_已啟用此觸發程序





參考文件

[SQL Server][Replication]:複寫使用者正在插入至 NOT FOR REPLICATION 識別欄位時...遭遇錯誤
http://sharedderrick.blogspot.tw/2017/06/sql-serverreplication-not-for.html

DISABLE TRIGGER (Transact-SQL)
https://msdn.microsoft.com/zh-tw/library/ms189748.aspx

停用(Disable)與啟用(Enable)「觸發程序(Trigger)」
http://sharedderrick.blogspot.tw/2010/09/disableenabletrigger.html

停用複寫的檢查條件約束
https://msdn.microsoft.com/zh-tw/library/ms190235.aspx

唯一條件約束與檢查條件約束
https://msdn.microsoft.com/zh-tw/library/ms187550.aspx#Check

2017-06-13

[PowerShell]:The trust relationship between this workstation and the primary domain failed:此工作站和主網域之間的信任關係失敗


使用 [PowerShell]:Reset-ComputerMachinePassword 來解決主網域與工作站之間的信任關係(trust relationship)失敗之問題。
不用操作多次的「系統內容」工具來退出網域,再重新加入網域。

若是遇到

The trust relationship between this workstation and the primary domain failed.
此工作站和主網域之間的信任關係失敗

-- 01_網域帳戶登入_失敗



重現錯誤的流程:

  1. VM 環境,且已經加入到 Windows AD(Active Directory) 網域
  2. 因故使用快照(Snapshot),將VM還原到特定時間點
  3. 再度登入網域環境時,將遭遇次錯誤

示範的作業系統:
Windows Server 2012 R2



[PowerShell]:Reset-ComputerMachinePassword

使用[PowerShell]:Reset-ComputerMachinePassword,重置此電腦的密碼,並使用此驗證到網域控制站。
解決主網域與工作站之間的信任關係(trust relationship)失敗之問題

Reset-ComputerMachinePassword 語法:

Reset-ComputerMachinePassword -Server {domain controller} -Credential {domain admin}


參數說明:

-Server:輸入網域控制站的名稱。

-Credential:輸入具備此操作權限的帳戶。之後 cmdlet 將產生提示視窗,請再輸入密碼。
於 Windows PowerShell 3.0 導入此參數。



範例:[PowerShell]:Reset-ComputerMachinePassword

步驟01:若遭遇網域帳戶登入失敗,先改用本機管理者帳戶登入,例如:


.\Administrator

-- 02_改用本機管理者登入




步驟02:執行:Reset-ComputerMachinePassword

Reset-ComputerMachinePassword -Server DC01 -Credential mydomain\dcdmin

-- 03_PowerShell



步驟03:輸入密碼

-- 04_PowerShell_輸入password



-- 05_PowerShell_輸入password後




步驟04:[PowerShell]:Restart-Computer,重新啟動電腦

Restart-Computer


-- 06_Restart-Computer





步驟05:重新啟動作業系統後,應可以回復正常,使用網域帳戶來登入此主機。



錯誤訊息

This computer could not authenticate with \\XYZ01.XYZ.XYZ, a Windows domain controller 
for domain XYZ , and therefore this computer might deny logon requests. 

This inability to authenticate might be caused by another computer on the same network
 using the same name or the password for this computer account is not recognized. 

If this message appears again, contact your system administrator.


-- 07_Windows_Event_Logs_NETLOGON

 

-- 08_網域帳戶_以SID方式呈現,失去驗證



-- 09_經過重新與網域控制站的驗證後,SID帳戶,已恢復為正確的名稱





解決方案

解決
The trust relationship between this workstation and the primary domain failed:此工作站和主網域之間的信任關係失敗。

可以使用以下的方案:

(一) [PowerShell]:Reset-ComputerMachinePassword

Reset-ComputerMachinePassword
https://msdn.microsoft.com/powershell/reference/5.1/microsoft.powershell.management/Reset-ComputerMachinePassword

(二) 退出網域後,再重新加入網域

"The trust relationship between this workstation and the primary domain failed" error when you log in to Windows 7
https://support.microsoft.com/en-us/help/2771040/-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed-error-when-you-log-on-to-a-computer-that-is-running-windows-7


(三) Netdom

適用於 Windows Server 2003, Windows Server 2008, Windows Server 2003 R2, Windows Server 2008 R2, Windows Server 2012, Windows Server 2003 with SP1, Windows 8
由於是明碼方式輸入帳戶密碼,請謹慎使用。

Netdom
https://technet.microsoft.com/en-us/library/cc788049(v=ws.11).aspx




參考資料

Fix: The trust relationship between this workstation and the primary domain failed
https://blog.blksthl.com/2013/03/18/fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/

"The trust relationship between this workstation and the primary domain failed" error when you log in to Windows 7
https://support.microsoft.com/en-us/help/2771040/-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed-error-when-you-log-on-to-a-computer-that-is-running-windows-7

VMware Knowledge Base (KB)
Connecting to linked clones in VMware Horizon View fails with the error: The trust relationship between this workstation and the primary domain failed (2084433)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2084433

Domain member: Maximum machine account password age
https://technet.microsoft.com/en-us/library/jj852252(v=ws.10).aspx

Netdom
https://technet.microsoft.com/en-us/library/cc788049(v=ws.11).aspx

Reset-ComputerMachinePassword
https://msdn.microsoft.com/powershell/reference/5.1/microsoft.powershell.management/Reset-ComputerMachinePassword

Restart-Computer
https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.management/restart-computer