Tuy có kích cỡ bé xíu, song Marxio Timer lại là một chú “robot” máy tính rất thông minh, đa năng và dễ sử dụng. Nó có thể giúp bạn thực hiện mọi công việc thường nhật trên PC cho dù bạn có quên, từ chuyện tắt mở máy tính, hiển thị thông báo nhắc nhở bạn, phát nhạc, chạy một ứng dụng bất kỳ cho đến khả năng tự động bấm chuột hoặc gõ phím! Với Marxio Timer, bạn có thể phối hợp rất nhiều tùy chọn phức tạp để tạo ra vô số “robot” máy tính giúp bạn giảm tải áp lực từ những công việc mang tính định kỳ...

Ưu điểm dễ nhận ra nhất ở Marxio Timer đó là việc hỗ trợ rất nhiều lệnh thường dùng trên máy tính, cung cấp rất nhiều tùy chọn hay, giao diện thân thiện và còn có cả phiên bản chạy trực tiếp từ ổ đĩa USB (không cần cài đặt).

Marxio Timer có dung lượng chỉ 752 KB, tương thích với hầu hết các hệ điều hành Microsoft Windows (kể cả những hệ điều hành mới nhất là Windows Vista và Windows 7) và hiện được cung cấp hoàn toàn miễn phí tại địa chỉ http://marxio- tools.net/download/marxio_timer_setup.exe. Ngoài ra, Marxio Timer còn có phiên bản chạy trực tiếp từ ổ đĩa USB. Sau đây là phần hướng dẫn chi tiết cách sử dụng Marxio Timer.

Ra lệnh cụ thể cho “robot” Marxio Timer:

Trên giao diện chương trình, từ vùng Execute action, bạn hãy bấm chuột để lựa chọn 1 trong 15 tính năng thường dùng nhất khi làm việc với chiếc máy tính. Lưu ý: Những tính năng mà chữ của nó có màu xám nhạt sẽ là những tính năng mà Marxio Timer không xử lý được (do đặc thù máy tính của bạn).

Sau đây là cách khai báo đối với từng tính năng một:

1. Tắt máy tính: từ vùng Execute action, bạn hãy chọn mục Turn off computer rồi tiếp tục đánh dấu kiểm trước tùy chọn Grace system shutdown nếu như bạn không muốn Marxio Timer tự động tắt máy tính khi mà vẫn còn rất nhiều chương trình chưa được lưu trữ (save) do đang làm việc dở dang.

2. Đăng xuất máy tính: từ vùng Execute action, bạn hãy chọn mục Logout computer rồi tiếp tục đánh dấu kiểm trước tùy chọn Grace logout nếu như bạn không muốn Marxio Timer tự động đăng xuất máy tính khi mà vẫn còn rất nhiều chương trình chưa được lưu trữ do đang làm việc dở dang.

3. Tái khởi động máy tính: từ vùng Execute action, bạn hãy chọn mục Restart computer rồi tiếp tục đánh dấu kiểm trước tùy chọn Grace restart nếu như bạn không muốn Marxio Timer tự động tái khởi động máy tính khi mà vẫn còn rất nhiều chương trình chưa được lưu trữ  do đang làm việc dở dang.

4. Đặt máy tính trong tình trạng tạm hoãn: từ vùng Execute action, bạn hãy chọn mục Suspend.

5. Để máy tính ngủ đông: từ vùng Execute action, bạn hãy chọn mục Hibernate.

6. Hiển thị một đoạn văn bản ngắn (chẳng hạn như một mẫu thông báo nhỏ): Từ vùng Execute action, bạn hãy chọn mục Display text, nhập vào một câu thông báo ngắn trong ô có nền màu vàng rồi bấm chuột lên nút Add to list (chiếc nút có biểu tượng là dấu cộng màu xanh lá cây) để lưu lại câu thông báo này trong danh sách. Bạn có thể tạo thêm một số câu thông báo nữa để sử dụng cho phù hợp với từng nội dung công việc. Hãy bấm chuột lên nút Remove from list (chiếc nút có biểu tượng là dấu trừ màu đỏ) khi cần xóa bớt một câu thông báo bất kỳ ra khỏi danh sách.

7. Phát một tập tin âm thanh: từ vùng Execute action, bạn hãy chọn mục Play sound, bấm chuột lên nút Browse để mở hộp thoại Select sound file to play, từ hộp thả xuống Look in của hộp thoại này, bạn hãy tìm đến thư mục có chứa tập tin nhạc (.mp3) cần mở, bấm chuột lên biểu tượng của nó rồi chọn nút Open. Hãy bấm chuột lên nút Play sound nếu muốn nghe thử tập tin âm thanh này rồi bấm chuột lên nút Add to list (chiếc nút có biểu tượng là dấu cộng màu xanh lá cây) để lưu lại tập tin âm thanh này trong danh sách. Bạn có thể nạp thêm một số tập tin âm thanh khác nữa để sử dụng cho phù hợp với từng nội dung công việc. Hãy bấm chuột lên nút Remove from list (chiếc nút có biểu tượng là dấu trừ màu đỏ) khi cần xóa bớt một tập tin âm thanh bất kỳ ra khỏi danh sách. Tùy chọn Repeat sẽ yêu cầu Marxio Timer phát đi phát lại tập tin âm thanh cho đến khi hết thời gian do bạn quy định.

8. Chạy một chương trình: từ vùng Execute action, bạn hãy chọn mục Run program, bấm chuột lên nút Browse để mở hộp thoại Select program to run, từ hộp thả xuống Look in của hộp thoại này, bạn hãy tìm đến thư mục có chứa tập tin chính của chương trình cần mở (tập tin .exe), bấm chuột lên biểu tượng của nó rồi chọn nút Open. Hãy bấm chuột lên nút Add to list (chiếc nút có biểu tượng là dấu cộng màu xanh lá cây) để lưu lại chương trình này trong danh sách. Bạn có thể nạp thêm một số chương trình khác nữa để sử dụng cho phù hợp với từng nội dung công việc. Hãy bấm chuột lên nút Remove from list (chiếc nút có biểu tượng là dấu trừ màu đỏ) khi cần xóa bớt một chương trình bất kỳ ra khỏi danh sách. Nếu đánh dấu kiểm ... Đọc thêm »

Giải phân mảnh cho ổ đĩa cứng là một trong những việc cần làm thường xuyên nếu bạn muốn duy trì sự nhẹ nhàng, hiệu quả cho hệ thống máy tính của mình. Tuy nhiên không phải ai cũng nhớ thực hiện vì đây cũng là việc chiếm mất khá nhiều thời gian của bạn. Disktrix DefragExpress là một lựa chọn tốt cho bạn: nó vừa giúp bạn giải phân mảnh ổ cứng đơn giản, nhanh chóng một cách đáng kinh ngạc lại vừa thực hiện việc này một cách hoàn toàn tự động.

Với một giao diện rất đơn giản và trực quan, bạn sẽ không phải mất nhiều thời gian tìm hiểu trong lần đầu tiên sử dụng chương trình. Ở cửa sổ chính, bạn sẽ thấy các phần như sau:

- Phần liệt kê sẵn tất cả các ổ đĩa trên máy tính cùng các thông tin liên quan (tên ổ đĩa, tổng dung lượng, dung lượng còn trống, tổng số file bị phân mảnh...).

- Phần Information cung cấp thông tin về mức tối ưu hóa (Optimization Level) cho ổ đĩa và thời gian thực hiện giải phân mảnh.

- Một biểu đồ hiển thị trực quan các thành phần của ổ đĩa cũng như hoạt động của chương trình trong quá trình giải phân mảnh.

Trong lần đầu tiên sử dụng, bạn cần bấm nút Settings để mở bảng thiết đặt các tùy chọn.

Chương trình có 2 kiểu hoạt động chính:

- Fast mode: chương trình sẽ xử lý tất cả các file bị phân mảnh mà không đụng đến phần không gian đĩa trống (thời gian thực hiện vì thế sẽ nhanh hơn).

- Thorough mode: ngoài việc dồn phân mảnh cho các file, chương trình sẽ gom lại phần không gian trống của ổ đĩa. Đặc biệt nếu chọn ô Move Frequently Used Files to High Performance Area, chương trình sẽ tự động xếp các file mà bạn thường dùng nhất vào một vị trí thích hợp trên bề mặt ổ cứng, tuy có làm tăng thời gian thực hiện nhưng bù lại ổ cứng sẽ hoạt động nhanh hơn.

Một chức năng đáng giá của chương trình là lập lịch để thực hiện giải phân mảnh tự động theo yêu cầu của người sử dụng. Để sử dụng được chức năng này, bạn bấm chọn vào ô kiểm Enable Schedule. Tiếp đó chọn ổ đĩa cần defrag rồi bấm nút Configure Schedule để mở của sổ điều chỉnh.

Tại cửa sổ này, mở thẻ Schedule bạn có thể yêu cầu chương trình tự động thực hiện theo thời gian biểu hàng giờ, hàng ngày, lúc khởi động hoặc khi máy tính rảnh rỗi... Ngoài ra nếu có yêu cầu cao hơn, hãy chọn thêm nút Advanced để thiết đặt cho những yêu cầu khác (bạn có thể tìm hiểu thêm trong quá trình sử dụng chương trình).

Sau khi đã thiết đặt xong, bạn bấm nút Defragment trên giao diện chính để trở về màn hình làm việc. Từ đây chương trình sẽ tự động thực hiện đúng theo những gì mà bạn đã thiết đặt, bạn không cần phải bận tâm đến việc giải phân mảnh cho ổ cứng nữa. Ngoài ra, bạn cũng có thể thực hiện công việc này thủ công bằng cách bấm vào nút Start Defragmenting.

Trong thực tế sử dụng, thời gian thực hiện công việc dồn đĩa lần đầu tiên có lâu hơn những lần thực hiện sau, vì bằng công nghệ độc đáo của mình, Disktrix DefragExpress giúp quá trình dồn đĩa diễn ra nhanh hơn (chỉ mất khoảng từ 1 đến 10 phút cho một ổ đĩa có dung lượng lớn và chứa nhiều file). Đây cũng là ưu điểm vượt trội của DefragExpress so với các chương trình cùng loại đúng như tên gọi của nó.

Giới thiệu

Cho đến phần này, chúng tôi đã giới thiệu cho các bạn khá nhiều kiểu test khác nhau có thể thực hiện trên Domain Controller của bạn bằng cách sử dụng Domain Controller Diagnostic Utility. Tuy nhiên vẫn còn đó một số kiểu test mà chúng tôi nghĩ là vẫn cần giới thiệu cho các bạn, và để kết thúc loạt bài này chúng tôi sẽ giới thiệu các kiểu test còn lại.

Register in DNS

Nếu bạn đang làm việc trên hệ điều hành Windows thì chúng tôi chắc chắn rằng bạn sẽ biết Active Directory hoàn toàn phụ thuộc vào các dịch vụ DNS, và mỗi một host trên mạng của bạn đều yêu cầu một bản ghi Host (A) trên máy chủ DNS của tổ chức. Những gì mà nhiều người không thực sự nhận ra là rằng, khi bạn tạo một miền nào đó (đầu tiên) trong một forest, sẽ có một số bản ghi DNS cụ thể của miền sẽ được tạo bên trong thư mục có tên DomainDnsZones. Thư mục này được định vị bên trong Forward Lookup Zones trong thư mục miền.

Thư mục DomainDnsZones giữ các bản ghi cho mỗi một Domain Controller. Không có các bản ghi, các máy chủ khác trên mạng sẽ không thể tìm ra được tài nguyên của Domain Controller. Chính vì vậy mà mỗi một Domain Controller cần phải tự đăng ký bên trong DNS. Đây chính là nơi mà test Register in DNS phát huy tác dụng của nó. Test này sẽ thẩm định rằng Domain Controller có thể đăng ký một bản ghi máy chủ.

Bạn có thể thực hiện test này bằng cách nhập vào lệnh dưới đây:

DCDIAG /Test:RegisterInDns /DnsDomain:<Active Directory Domain DNS Name>

Cho ví dụ, nếu miền của bạn có tên Contoso.com thì lệnh cú pháp câu lệnh sẽ như sau:

DCDIAG /Test:RegisterInDns /DnsDomain:Contoso.com

Replications

Windows 2000 Server và các phiên bản sau đó của Windows Server đều sử dụng một mô hình multimaster domain. Điều này có nghĩa rằng mỗi một Domain Controller đều có một bản copy cơ sở dữ liệu Active Directory của chính nó và các nâng cấp có thể được thực hiện trực tiếp cho bất cứ copy nào. Khi một nâng cấp nào đó được thực hiện đối với cơ sở dữ liệu Active Directory thì nâng cấp sẽ được tạo bản sao đến các bộ điều khiển miền khác.

Test này sẽ kiểm tra để bảo đảm rằng các nâng cấp đang xuất hiện phù hợp. Nếu có một độ quá trễ nào đó xuất hiện trong quá trình nâng cấp thì các bộ điều khiển miền (Domain Controller) sẽ mất đồng bộ và khả năng xung đột sẽ xảy ra.

Bạn có thể thực hiện test này bằng cách nhập vào lệnh dưới đây:

DCDIAG /TEST:Replications

RID Manager

Bất cứ khi nào bạn tạo một đối tượng Active Directory mới, chẳng hạn như một người dùng hoặc một nhóm thì Windows cũng đều gán cho nó một Security Identifier (SID) duy nhất. Security Identifier (SID) là hư cấu của một domain SID chung cho tất cả các đối tượng bên trong miền và relative identifier (RID) duy nhất với miền. RID master cung cấp cho mỗi một Domain Controller bên trong domain một số RID mà nó có thể sử dụng khi các đối tượng mới được tạo. Khi số RID gần hết thì domain controller sẽ phát một yêu cầu đến RID master để yêu cầu các RID bổ sung. Nếu Domain Controller không thể liên lạc với RID Master thì không một đối tượng bổ sung nào được tạo trên Domain Controller đó khi sắp hết số lượng RID cũ.

Test RID Manager sẽ cho phép bạn thẩm định rằng sc có thể nhận ra và liên lạc với RID Master, và rằng RID Master gồm có các thông tin thích hợp. Bạn có thể chạy test này bằng cách nhập vào lệnh dưới đây:

DCDIAG /Test:RidManager

Services

Trong Windows Server 2008, Active Directory hiện được liệt kê như một dịch vụ bên trong Service Control Manager. Như những gì bạn có thể đoán, Active Directory hiện phức tạp hơn một chút so với những gì bạn đầu mới xuất hiện. Active Directory Domain Service có một số dịch vụ phụ thuộc, một trong số đó phải kể đến đó là DNS Server (nếu nó được hiện diện trên máy chủ), Kerberos Key Distribution Center, Intersite Messaging và File Replication Service.

Bạn có thể sử dụng test này để bảo đảm rằng Active Directory Domain Service và tất cả các dịch vụ đang được hỗ trợ của nó hiện đang hoạt động tốt. Để thực hiện test, bạn sử dụng lệnh dưới đây:

DCDIAG /Test:Services

System Log

Theo tài liệu minh chứng của Microsoft, test System Log sẽ kiểm tra hệ thống để bảo đảm rằng không có lỗi nào xuất hiện. Điều này nghe test này sẽ phân tích cú pháp bản ghi sự kiện để tìm kiếm ra các lỗi. Có thể một trong số khâu trong đó sẽ thực hiện như vậy nhưng đó không phải là những gì xuất hiện ở đây khi bạn thực hiện test này.

Khi chạy test này, Domain Controller Diagnostic Utility sẽ bắt dầu bằng cách nhận diện máy chủ của nó và Active Directory forest. Sau đó nó sẽ thực hiện hành động kiểm tra kết nối, bản ghi hệ thống và một loạt các test partition trên các Active Directory Partitions (ForestDnsZones, DomainDnsZones, Schema, Configuration,…).

Bạn có thể chạy test System Log bằng cách nhập vào lệnh sau:

DCDIAG /Test:SystemLog

Topology

Windows Server sử dụng Directory System Agent (DSA) để cung cấp sự truy cập đến các kho dữ liệu. Directory Service Agent là hư cấu của các dịch vụ khác nhau và các quá trình làm cho thuận tiện sự truy cập đó. DSA là một phần của hệ thống Local System Authority và được truy cập thông qua giao thức LDAP.

Khi nhiều bộ điều khiển miền cùng sử dụng một lúc, mỗi một Domain Controller phải có một thông tin về topo để liên kết nó với các DSA khác. Test này sẽ hợp lệ hóa topo mà Windows đã tạo ra được kết nối hoàn toàn với tất cả DSA.

Một thứ quan trọng cần phải biết về test này là, nó là một trong những kiểu test hiếm mà không chạy mặc định. Nó phải được thực thi một cách thủ công. Bạn có thể thực hiện test này bằng cách nhập vào lệnh dưới đây:

DCDIAG /Test:Topology

Verify References

Test Verify References bảo đảm rằng các tham chiếu hệ thống được yêu cầu bởi File Replication Service và sơ sở hạ tầng tạo bản sao chung không bị đụng chạm. Bạn có thê thực hiện bằng cách sử dụng lệnh dưới đây:

DCDIAG /Test:VerifyReferences

Verify Enterprise References

Test Verify Enterprise References cũng giống như Verify References. Nó kiểm tra để bảo đảm rằng các tham chiếu được yêu cầu bởi File Replication Service và sơ sở hạ tầng tạo bản sao chung là không bị đụng chạm. Những gì tạo nên sự khác biệt giữa hai lệnh này là nó kiểu tra các tham chiếu của dịch vụ bản sao file và sơ sở hạ tầng tạo bản sao nói chung trên toàn bộ các Domain Controller trong toàn doanh nghiệp.

This is another one of those tests that are not run by default. You can perform this test by entering the following command:

Đây cũng là một test không chạy mặc định và bạn có thể thực hiện băng cách sử dụng lệnh sau:

DCDIAG /Test:VerifyEnterpriseReferences

Verify Replicas

Đây là một test khác cũng không chạy mặc định. Ý tưởng cơ bản phía sau test này là Windows cho phép bạn tạo các partition thư mục ứng dụng và các partition đó có thể được tái tạo sang các máy chủ khác. Test này sẽ cho phép bạn bảo đảm rằng tất cả các máy chủ bản sao đều chứa các bản sao thích hợp. Thực hiện test bằng sử dụng lệnh dưới đây:

DCDIAG /Test:VerifyReplicas

Kết luận

Như những gì các bạn thấy, Domain Controller Diagnostic Utility có thể thực hiện rất nhiều các kiểu test khác nhau. Qua bài chúng tôi đã giới thiệu cho các bạn rất nhiều kiểu test mà các bạn có thể thực hiện, cuối cùng xin chúc các bạn thành công.

Giới thiệu

Trong phần trước của loạt bài này, chúng tôi đã giới thiệu cho các bạn một số kiểu test để các bạn có thể thực hiện bằng cách sử dụng Domain Controller Diagnostic Utility. Mặc dù cho đến đây, chúng tôi đã giới thiệu khá nhiều kiểu test nhưng vẫn có đó nhiều kiểu mà các bạn có thể thực hiện. Và trong phần này, chúng tôi sẽ chọn ra một trong số những kiểu tiêu biểu đó và giới thiệu để các bạn có thể thực hiện với Domain Controller Diagnostic Utility.

Locator Check

Locator Check là một trong những kiểu test quan trọng mà bạn có thể thực hiện bằng DCDIAG. Vấn đề chắc hẳn các bạn đã biết, Active Directory gán các role Flexible Single Master Operations (FSMO) khác nhau cho các bộ điều khiển miền nào đó bên trong forest. Các role FSMO toàn cục ban đầu được gán cho bộ điều khiển miền đầu tiên trong forest. Tuy nhiên cũng có một số role FSMO mức miền được gán mặc định cho bộ điều khiển miền đầu tiên trong mỗi miền.

Locator Check sẽ thực hiện quá trình test để bảo đảm rằng các máy chủ đang nắm giữ các role FSMO toàn cục được biết đến và có thể được định vị. Quan trọng hơn nữa, nó kiểm tra để bảo đảm rằng các máy chủ giữ các role FSMO toàn cục đang đáp trả cho các yêu cầu.

Việc thực hiện test này tương đối đơn giản. Tất cả những gì bạn cần thực hiện là nhập vào lệnh sau:

DCDIAG /TEST:LocatorCheck

Rõ ràng, đây là một ví dụ đơn giản nhất về cách bạn sẽ chạy test locator check. Ngoài ra bạn vẫn có các tùy chọn khác như chỉ định bộ điều khiển miền nào đó và thiết lập các tiêu chuẩn thẩm định như bạn vẫn thực hiện với các test khác.

Intersite Test

Việc phụ thuộc vào topo của Active Directory, Intersite cũng là một test quan trọng. Khi bạn chạy test này, Domain Controller Diagnostic Utility sẽ thực hiện một loạt các hành động test để xem có bất cứ vấn đề gì với các đầu cầu mà có thể làm cho các thông tin Active Directory bị tạo bản sao qua các biên giới của site hay không.

Cú pháp được sử dụng để chạy test này gần giống như cú pháp được sử dụng cho locator check. Nếu bạn muốn thực hiện, chỉ cần nhập vào lệnh sau:

DCDIAG /Test:Intersite

KCCEvent

Một test có liên quan đến việc sao chép khác đó là KCCEvent. Test này được sử dụng để bảo đảm rằng Knowledge Consistency Checker (KCC) đang làm việc, và rằng liệu nó có đang thực hiện nhiệm vụ mà không gây ra bất cứ lỗi nào. Bạn có thể chạy KCCEvent bằng cách nhập vào lệnh sau:

DCDIAG /Test:KCCEvent

KnowsofRoleHolders

Knows of Role Holders là kiểu test để kiểm tra xem Directory Service Agent có biết máy chủ nào đang giữ các role Flexible Single Operations Master. Nếu chỉ muốn chạy một cách đơn giản thì bạn có thể thực hiện bằng cách nhập vào lệnh sau:

DCDIAG /Test:KnowsOfRoleHolders

Mặc dù test này sẽ thường thực hiện khá tốt công việc của nó, song đôi khi bạn có thể muốn kiểm tra xem bộ điều khiển miền nào mà Directory Service Agent nghĩ rằng đang nắm giữ các role. Nếu bạn muốn nhận định các máy chủ riêng biệt, cần phải chạy test này trong chế độ chi tiết. Để thực hiện điều đó, hãy nhập vào lệnh sau:

DCDIAG /Test:KnowsofRoleHolders /v

Machine Account

Trong môi trường Active Directory, các máy chủ và máy trạm được gia nhập vào một miền. Quá trình gia nhập một máy vào một miền này cần phải tạo cho mỗi máy một tài khoản. Giống như tài khoản người dùng, tài khoản máy cũng có một mật khẩu tương ứng và một số các thuộc tính khác được thiết kế để phân biệt các máy với nhau. Nếu tài khoản máy bị lỗi hoặc mất đồng bộ với Active Directory thì máy tương ứng với tài khoản đó sẽ không thể kết nối vào miền. Tuy nhiên, có một test giúp bạn có có thể kiểm tra được sự toàn vẹn của tài khoản máy. Bạn có thể thực hiện test này bằng cách nhập vào lệnh dưới đây:

DCDIAG /Test:MachineAccount

Trong quá trình làm việc với Active Directory, rất có thể xuất hiện một số tình huống mà nguyên nhân ở đó là mật khẩu của tài khoản không được đồng bộ với mật khẩu của tài khoản máy được lưu trong cơ sở dữ liệu Active Directory.

Nếu tài khoản của máy gặp phải vấn đề như vậy, có một số tiếp lệnh có thể giúp bạn sửa vấn đề đó. Một trong những tiếp lệnh như vậy là /FixMachineAccount, tiếp lệnh này sẽ thiết lập lại cờ cho các tài khoản. Nếu không khắc phục được vấn đề trên thì bạn có thể cần phải tạo lại tài khoản máy bằng cách sử dụng tiếp lệnh /RecreateMachineAccount.

Naming Context Security Descriptors

Một trong những test khó hiểu phải kể đến ở đây là kiểm tra xem các bộ nhận diện bảo mật trên các bối cảnh tên (naming context) có hoạt động đúng không. Nếu các bộ nhận diện bảo mật không hợp lệ thì sự tái tạo có thể sẽ thất bại. Bạn có thể chạy test này bằng cách nhập vào lệnh dưới đây:

DCDIAG /Test:NCSecDesc

NetLogons

Một test tương tự có liên quan đến bản sao đó là NetLogons. Test này sẽ kiểm tra xem bản sao có bị thất bại vì thiếu đặc quyền đăng nhập hay không. Bạn có thể chạy test này bằng cách nhập vào lệnh dưới đây:

DCDIAG /Test:NetLogons

Objects Replicated

Một test quan trọng nữa có liên quan đến quá trình tạo bản sao là Objects Replicated. Test này được sử dụng chính để xác nhận rằng các tài khoản máy tính đã sao chép trên tất cả các bộ điều khiển miền của bạn, nhưng nó cũng được sử dụng để kiểm tra xem các kiểu đối tượng khác cũng có được sao chép chưa.

Để sử dụng test này, bạn sẽ phải biết tên riêng (DN) của đối tượng muốn test. Nếu đối tượng mà bạn muốn kiểm tra không phải là tài khoản máy thì bạn cần phải biết được naming context của đối tượng. Cú pháp cho test này như sau:

DCDiag /Test:ObjectsReplicated /ObjectDN:<object’s distinguished name> /N:<object’s naming context>

Outbound Secure Channels

Khi các máy lưu các mật khẩu của người dùng và các thiết lập bảo mật khác, thì Domain Controller là một trong những máy chủ nhậy cảm nhất trên mạng. Chính vì vậy, Microsoft đã cấu hình các Domain Controller để truyền thông với nhau trên một kênh an toàn bất cứ khi nào có thể. Điều này giúp ngăn chặn được vấn đề người khác sử dụng tấn công sniff để đánh cắp các thông tin Active Directory khi nó tạo bản sao từ một Domain Controller này sang Domain Controller khác.

Theo định nghĩa, một kênh an toàn là một kết nối RPC (remote procedure call) được thẩm định giữa hai máy trong một miền với bối cảnh bảo mật được thiết lập để sử dụng cho việc ký và mã hóa các gói RPC.

Chính vì vậy không hề ngạc nhiên khi Domain Controller Diagnostic Utility cung cấp một kiểu test để kiểm tra các kênh an toàn gửi đi. Đây là một trong những kiểu test không được chạy mặc định, chính vì vậy bạn cần phải tự chạy nó nếu muốn sử dụng. Cú pháp của lệnh như sau:

DCDIAG /Test:OutboundSecureChannels /TestDomain:<yourdomain>

Thông thường, test này chỉ kiểm tra các Domain Controller bên trong site hiện hành. Tuy nhiên bạn cũng có thể test các site bên ngoài bằng cách thêm vào tiếp lệnh /NoRestriction.

Kết luận

Trong phần này, chúng tôi đã giới thiệu cho các bạn thêm một số kiểu test có thể thực hiện với bộ điều khiển miền của mình bằng cách sử dụng tiện ích chuẩn đoán Domain Controller Diagnostic Utility. Tin tưởng nó hay không, các bạn hãy thực hiện để biết đích xác về kết quả của nó. Do vẫn còn một số kiểu test nữa nên trong phần tiếp theo của loạt bài này chúng tôi sẽ giới thiệu tiếp cho các bạn về các test còn lại.

Chúng tôi đã kết thúc phần trước trong loạt bài này bằng việc nói về một số kiểu test riêng mà bạn có thể thực hiện bằng công cụ chuẩn đoán Domain Controller. Trong phần này, chúng tôi sẽ tiếp tục và đề cập đến một số kiểu test khác.

DCPROMO

Một số kiểu test hiện hữu thông qua tiện ích chuẩn đoán Domain Controller thường ít được biết đến. Tuy nhiên ngược với sự thật đó chúng lại rất hữu dụng, test DCPROMO là một trong số các trường hợp đó. Nó được thiết kế để cho phép bạn test sự sẵn sàng của máy chủ trước khi tăng cường vào một domain controller. Khi đó nó giúp cho việc tăng cường một máy chủ vào một domain controller sẽ khá là một quá trình đơn giản. Bạn chỉ cần nhập vào lệnh DCPROMO, kích Next một vài lần là có thể tìm được những vấn đề cần phải điều chỉnh.

Nếu sử dụng test DCPROMO, bạn sẽ phải sử dụng ít nhất hai chuyển đổi lệnh thêm với nó. Chuyển đổi lệnh đầu tiên mà bạn cần phải sử dụng đó là /DNSDomain. Bạn phải sử dụng chuyển đổi lệnh này để mách bảo tiện ích chuẩn đoán Domain Controller miền nào máy chủ sẽ được tạo một Domain Controller bên trong.

Tiếp sau chuyển đổi lệnh /DNSDomain là chuyển đổi lệnh thứ hai nhằm mách bảo cho tiện ích chuẩn đoán những ý định của bạn cho máy chủ là gì. Cho ví dụ, nếu máy chủ sẽ là một Domain Controller nằm trong một forest mới thì nó cần phải được test khác với náy chủ sẽ là một Domain Controller mở rộng trong miền đang tồn tại.

Các chuyển đổi lệnh mà bạn sử dụng ở đây là để mách bảo tiện ích chuẩn đoán cách Domain Controller sẽ phù hợp với cấu trúc Active Directory đang tồn tại như thế nào. Các chuyển đổi lệnh đó là:

/NewForest
/NewTree
/ChildDomain
/ReplicaDC

Cho ví dụ, nếu bạn muốn sử dụng máy chủ như một Domain Controller mở rộng trong một miền đang tồn tại có tên Contoso.com thì cú pháp đầy đủ của lệnh sẽ là:

DCDIAG /test:DCPROMO /DNSDomain:Contoso /ReplicaDC

Tuy nhiên có một vấn đề mà chúng tôi muốn đề cập đến ở đây là nếu bạn sử dụng chuyển đổi lệnh /NewTree thì bạn sẽ phải sử dụng chuyển đổi lệnh thứ ba mang tên /ForestRoot. Chỉ cần đặt sau chuyển đổi lệnh /ForestRoot một dấu hai chấm và tên của miền gốc (/ForestRoot:Contoso.com).

DNS

Có thể nhiều bạn cho tiện ích chuẩn đoán Domain Controller như một cơ chế cho việc chạy các test chuẩn đoán đối với các Domain Controller. Tuy vậy, tiện ích này lại có một loạt các test đã được thiết kế để giúp bạn chuẩn đoán các vấn đề xảy ra với máy chủ DNS của bạn. Điều này không hề ngạc nhiên vì Active Directory hoàn toàn phụ thuộc vào Domain Name Services và Domain Controller đầu tiên trong forest thường được cấu hình để thực hiện như một máy chủ DNS.

DNS test được sử dụng cho khá nhiều kiểu test khác nhau, bất cứ test nào cũng đều có thể được thực hiện một cách riêng rẽ. Nếu bạn gọi một DNS test nhưng không chỉ định bất cứ một chuyển đổi phụ thêm nào thì công cụ chuẩn đoán sẽ chạy tất cả như các test nhỏ bên trong nó. Test được bỏ qua bao gồm các tên miền ngoài. Chúng tôi sẽ giới thiệu về kiểu test này trong chốc lát. Tuy nhiên trước khi thực hiện, chúng tôi muốn cung cấp cho bạn một danh sách các test có thể được thực hiện khi DNS test chạy mà không có bất cứ một chuyển đổi lệnh mở rộng nào. Hình A bên dưới thể hiện một số kiểu DNS test mặc định như thế nào khi được thực thi.

Hình  A

Hình B: Đây là những gì thấy được khi thực hiện DNS test mặc định

Ở trên chúng tôi đã đề cập rằng chỉ có test không được chạy mặc định khi bạn chỉ định rằng bạn muốn test cấu hình DNS là test giải pháp tên bên ngoài. Có một số chuyển đổi lệnh bạn có thể sử dụng nếu muốn chạy kiểu test này.

Một tùy chọn ở đây là sử dụng chuyển đổi lệnh /DNAAll. Chuyển đổi lệnh này mách bảo tiện ích chuẩn đoán chạy tất cả các test có liên quan đến DNS, gồm có test giải pháp tên bên ngoài. Cú pháp của lệnh này như sau:

DCDIAG /TEST:DNS /DNSAll

Bạn cũng có một tùy chọn cho việc gọi một test tên bên ngoài nào đó thay cho việc bó bọc test với mọi test có liên quan đến DNS mà tiện ích có thể chạy. Nếu bạn muốn gọi một test tên bên ngoài nào đó, bạn có thể thực hiện bằng cách chỉ định chuyển đổi lệnh /DNSResolveExtName.
Trong trường hợp bạn vẫn đang phân vân, kiểu test giải pháp tên bên ngoài có thể thử giải quyết với tên miền Microsoft.com. Mặc dù vậy, bạn có tể chỉ định một tên miền bên ngoài khác để sẽ được giải quyết bằng việc thêm chuyển đổi lệnh /DNSInternetName, kết hợp với tên mà bạn muốn giải quyết.

SysVolCheck

Một trong những kiểu test đơn giản nhất mà tiện ích chuẩn đoán có thể thực hiện là SysVolCheck. Kiểu test này thực hiện một số test cơ bản đối với các partition Active Directory khác nhau gồm có các vùng DNS của forest, vùng DNS của miền, lược đồ, partition cấu hình và trên các partition miền. Bạn có thể thấy những gì ở kiểu test SysVolCheck này khi thực thi trong hình C.

Hình C

Kiểu test SysVolCheck thực hiện một số test kết nối ban đầu, sau đó test các partition Active Directory khác.

FrsEvent

Test cuối cùng mà chúng tôi muốn đề cập ở đây là FRSEvent. FRS chính là viết tắt của cụm từ File Replication Service. Kiểu test này sẽ kiểm tra xem  File Replication Service có cảm thấy bất cứ lỗi hoạt động nào không. Điều này là quan trọng vì nếu FRS gặp sự cố thì các Domain Controller có thể mất đồng bộ, điều đó có thể làm cho các chính sách không được áp dụng đúng cách cho tới khi vấn đề được khắc phục.

Kết luận

Trong phần này, chúng tôi đã giới thiệu cho các bạn một số kiểu test để các bạn có thể chạy bằng cách sử dụng tiện ích chuẩn đoán Domain Controller. Trong phần tiếp theo của loạt bài này, chúng tôi sẽ giới thiệu thêm một số kiểu test nữa.

Cho đến đây các bạn đã biết được rằng Domain Controller Diagnostic Utility có rất nhiều vấn đề mà bạn có thể sử dụng để cấu hình tiện ích chạy theo cách thích hợp nhất cho mỗi tình huống riêng của mình. Chúng tôi đã giới thiệu cho các bạn về các tiếp lệnh, còn bây giờ sẽ quay trở về các test riêng biệt mà tiện ích có khả năng thực hiện.

Advertising – quảng bá dịch vụ

Bài test đầu tiên mà bạn có thể thực hiện là advertising. Test này thực hiện một hành động kiểm tra để tìm ra xem Directory System Agent hiện có advertising bản thân nó hay không. Nếu Directory System Agent hiện đang advertising bản thân nó thì test sẽ bảo đảm rằng sự quảng bá sẽ liệt kê domain controller với những khả năng của Directory System Agent.

Trong trường hợp bạn không quen với khái niệm Directory System Agent, thì cần phải hiểu rằng, Directory System Agent (thường được viết tắt là DSA), là một bộ sưu tập các dịch vụ và các quá trình chạy trên domain controller. Công việc của nó là cung cấp sự truy cập vào cơ sở dữ liệu Active Directory. DSA là một thành phần con trong Local System Authority (LSA). Lý do tại sao nó lại liên quan đến các quá trình và dịch vụ như vậy là vì khả năng cung cấp nhiều cơ chế để máy khách có khả năng truy cập.

Có thể được biết đến nhiều nhất trong các cơ chế này chính là Light Weight Directory Access Protocol, hay còn được viết tắt là LDAP. LDAP là một giao thức mà thông qua đó, hầu hết các hệ điều hành Windows gần đây đều sử dụng để truy vấn Active Directory. Các máy khách cũ hơn vẫn yêu cầu sự truy cập DSA, tuy nhiên điển hình vẫn được thực hiện thông qua Security Account Manager (SAM). Điều này là do không có cơ chế nào để truy cập DSA. Cho ví dụ, Microsoft exchange truyền thông với DSA bằng các cuộc gọi MAPI. Các DSA cũng truyền thông với một DSA khác bằng cách sử dụng các cuộc gọi thủ tục từ xa.

CheckSDRefDom

Test này sẽ thẩm định rằng tất cả các partition chứa thư mục ứng dụng có bộ chỉ thị bảo mật cho các miền tham chiếu thích hợp. Bài test này sẽ vô nghĩa với những người không thành thạo về Active Directory. Chính vì vậy chúng tôi sẽ dành một chút thời gian để giới thiệu về bài test này là gì.

Có thể các bạn đã biết điều này, mỗi đối tượng trong Active Directory gồm có một bộ chỉ thị bảo mật. Công việc của bộ chỉ thị bảo mật là duy trì một danh sách các thông tin điều khiển truy cập. Thông thường, bộ chỉ thị bảo mật đi kèm thường làm việc tốt cho việc duy trì bản ghi về những ai đã truy cập và các thành phần mà họ truy cập là thành phần nào. Tuy nhiên vấn đề có thể xuất hiện ở đây nếu một tổ chức sử dụng các partition thư mục ứng dụng (trước đây được biết đến với tên Active Directory Application Mode hoặc ADAM). Lý do cho điều đó là rằng các partition thư mục ứng dụng là miền độc lập. Trong thực tế, có thể tạo một partition thư mục ứng dụng và sau đó tạo bản sao cho các bộ điều khiển miền khác trong nhiều miền. Do có thể thực hiện được điều đó nên Windows gán một bộ chỉ thị bảo mật có tham chiếu miền co mỗi một partition thư mục ứng dụng khi được tạo.

Miền tham chiếu này sẽ thông báo cho bạn về partition thư mục ứng dụng mà tên miền nào sử dụng khi một giá trị miền cần phải nhập vào bên trong một bộ chỉ thị bảo mật. Windows có rất nhiều rule để phân biệt tên miền nào được sử dụng. Đơn giản hóa, nếu bạn tạo một partition miền ứng dụng mới không phải là con của bất cứ partition nào và miền tham chiếu của bộ chỉ thị bảo mật sử dụng miền forest root như tên miền để sử dụng bên trong các bộ chỉ thị bảo mật khác nhau. Nếu partition thư mục ứng dụng là con của một đối tượng nào đó thì nó sẽ đảm nhận miền tham chiếu bộ chỉ thị bảo mật của đối tượng cha của nó.

CheckSecurityError

Test tiếp theo mà chúng tôi muốn giới thiệu cho các bạn là Check Security Error. Không giống như test trước mà chúng tôi đã giới thiệu cho các bạn. Check Security Error không hoạt động mặc định. Nếu muốn chạy test này, bạn phải tự chỉ định nó bên trong lệnh DCDIAG.

Khi chạy test này, DCDIAG sẽ tìm ra các lỗi liên quan đến vấn đề bảo mật, cũng như các lỗi có thể liên quan, sau đó cố gắng chuẩn đoán vấn đề. Có một tham số tùy chọn mà bạn có thể sử dụng với tiếp lệnh này. Tiếp lệnh /ReplSource cho phép bạn chỉ định bộ điều khiển miền cụ thể để chạy test. Bạn có thể sử dụng bất cứ bộ điều khiển miền nào mong muốn, không cần quan tâm đến trạng thái lỗi của nó hoặc nó có phải là đối tác hiện hành hay không. Đơn giản chỉ cần nhập vào tên của test (CheckSecurityError), và gắn thêm vào đó tiếp lệnh /ReplSource, dấu hai chấm và tên của domain controller mà bạn muốn test.

Connectivity

Connectivity là một trong những test hữu dụng nhất mà bạn có thể thực hiện với nó. Trong thực tế, test này rất quan trọng đến nỗi thậm chí DCDIAG không cho phép bạn bỏ qua. Nếu bạn chạy một instance mặc định của DCDIAG thì Connectivity sẽ chạy hoàn toàn tự động.

Connectivity sẽ kiểm tra xem các bộ điều khiển miền đã được đăng ký trong DNS chưa. Nó cũng kiểm tra xem liệu nó có thể ping mỗi domain controller và có thể thiết lập được kết nối LDAP và RDP hay không.

CrossRefValidation

Đây là một test mà bạn sẽ không thể thấy nhiều tài liệu nó về nó. Những gì mà chúng tôi có thể giới thiệu cho các bạn về nó cũng giống như các tham chiếu không chính thức. Nếu các bạn bắt gặp một lỗi hợp lệ hóa tham chiếu thì vấn đề có thể được giải quyết bằng cách sử dụng ADSI edit để remove đối tượng gây lỗi đó.

Chúng tôi cũng muốn chỉ ra rằng nếu sử dụng ADSI edit sai, bạn có thể phá hủy Active Directory của mình. Chính vì vậy, hãy thực hiện một backup toàn bộ trạng thái hệ thống cho các bộ điều khiển miền từ trước khi thực hiện bất cứ sự thay đổi nào.

CutOffServers

Test cuối cùng của chúng tôi là về Cut off Servers. Ý tưởng cơ bản nằm trong test này là trong hầu hết các trường hợp, các bộ điều khiển miền đều có một hoặc nhiều đối tác bản sao. Nếu đối tác sao chép của domain controller gặp vấn đề thì domain controller có thể sẽ không được cập nhật các nâng cấp của Active Directory và DCDIAG sẽ báo cáo lỗi Cut off Servers.

Một mánh có thể giải quyết được vấn đề này là bạn phải chỉ ra những đối tác bản sao là domain controller là gì. Phương pháp thực tế có nhiều thay đổi phụ thuộc vào các phiên bản Windows, tuy nhiên trong Windows Server 2003, bạn có thể tra cứu các đối tác bản sao thông qua Active Directory Site and Services console.

Khi mở giao diện hình cây, bạn hãy mở mục Site để hiển thị danh sách các site trong Active Directory của mình. Tiếp đến, kích đúp vào site chứa domain controller mà bạn muốn kiểm tra. Tiếp đến, mở phần thư mục Servers, sau đó là thư mục tương ứng với tên của domain controller mà bạn quan tâm đến. Cuối cùng là kích đúp vào mục NTDSSettings, khi đó Windows sẽ hiển thị danh sách các đối tượng kết nối. Danh sách này sẽ hiển thị các đối tác bản sao trong cột From Server.

Kết luận

Trong phần này, chúng tôi đã giới thiệu cho các bạn về một số bài test chạy với tiện ích DCDIAG. Trong phần tiếp theo của loạt bài này, chúng tôi sẽ tiếp tục giới thiệu cho các bạn về một số bài test khác.

Trong phần đầu của loạt bài này, chúng tôi đã giới thiệu cho các bạn rằng, nếu muốn chuẩn đoán các vấn đề với một domain controller, bạn chỉ cần nhập vào lệnh DCDIAG, hoặc có thể sử dụng bất cứ tiếp lệnh hiện hữu nào phù hợp để kiểm tra các thuộc tính cụ thể của domain controller quan tâm. Trong phần hai này, chúng tôi sẽ giới thiệu một số tiếp lệnh nữa, tuy nhiên số lượng các tiếp lệnh có thể giới thiệu là rất lớn nên trong bài này chúng tôi chỉ giới thiệu một số tiếp lệnh điển hình sau đó sẽ giới thiệu về một số bài test cho một vài trường hợp riêng mà các bạn có thể tự thực hiện.

/C

Chúng tôi đã đề cập rằng, chỉ cần nhập vào lệnh DCDIAG mà không cần bất cứ tiếp lệnh nào, Domain Controller Diagnostic Utility sẽ thực hiện một bộ công cụ đầy đủ cho việc test domain controller của bạn. Tuy nhiên có một số test mà Domain Controller Diagnostic Utility có khả năng thực hiện nhưng nó không thực hiện một cách mặc định đơn thuần như vậy.

Nếu bạn không thực sự chắc chắn về những gì sẽ diễn ra với domain controller của mình, hãy chạy lệnh DCDIAG kèm theo với tiếp lệnh /C. Thao tác này sẽ mách bảo DCDIAG rằng bạn muốn thực hiện một tập toàn diện các test. Domain Controller Diagnostic Utility sẽ chạy mọi test màm nó biết cách chạy, trừ các test DCPROMO và RegisterInDNS, đây là hai test mà chúng tôi sẽ giới thiệu cho các bạn sau.

Bạn cần phải lưu ý rằng việc chạy một tập toàn bộ các test sẽ làm tiêu tốn rất nhiều thời gian. Nếu có các test mà bạn biết rằng không cần chạy, khi đó bạn có thể sử dụng tiếp lệnh /C kết hợp với tiếp lệnh /SKIP. Sau đó nối thêm vào dấu hai chấm và tên của test mà bạn muốn bỏ qua.

/F

Ở phần đầu của phần 1, chúng tôi đã giới thiệu những gì có thể chạy với lệnh DCDIAG khi không có việc chỉ định các tiếp lệnh như vậy. Bạn có thể quay trở lại để tham khảo trong phần 1, đầu ra rõ ràng là khá dài. Khi chúng tôi tạo một capture màn hình đó, chúng tôi chỉ chạy một tập mặc định các test cho domain controller của mình. Đầu ra có thể sẽ dài hơn rất nhiều nếu  chỉ định các test bổ sung hoặc nếu các test phát hiện ra có các vấn đề nào đó với domain controller.

Trong một số trường hợp, việc đọc kết quả thu được từ màn hình khi các test được thực hiện là không thiết thực. DCDIAG có thể xuất ra dữ liệu nhanh hơn khả năng đọc của bạn. Vậy có cách giải quyết nào cho trường hợp này. Đó chính vai trò xuất hiện của tiếp lệnh /F. Tiếp lệnh này cho phép bạn có thể ghi các kết quả test vào một file bản ghi. Theo cách đó, có thể đọc các kết quả thu được một cách thoải mái. Quan trong hơn nữa là có được bản copy vĩnh viễn đầu ra mà bạn muốn tham khảo này.

Để sử dụng tiếp lệnh /F, chỉ cần nối thêm dấu hai chấm và đường dẫn, tên file của file bản ghi  muốn tạo. Cho ví dụ, nếu muốn tạo một file bản ghi mang tên TEST.LOG, hãy nhập DCDIAG /F:TEST.LOG. Cần lưu ý rằng khi chỉ định tiếp lệnh /F, đầu ra sẽ được chuyển hướng hoàn toan đến một file bản ghi. Điều này có nghĩa rằng đầu ra test không phải ghi tất cả ra màn hình. Với một số hoạt động liên quan đến nhiều test, máy chủ có thể gặp trục trặc nhưng các test vẫn được thực hiện.

/FIX

Cho đến đây, tất cả các tiếp lệnh mà chúng tôi đã giới thiệu là các phương pháp chuẩn đoán nguyên bản. Khi bạn sử dụng chúng, chúng sẽ làm cho DCDIAG chạy các test của nó theo các cách nào đó, tuy nhiên DCDIAG chỉ báo cáo các kết quả test mà không thể khắc phục được vấn đề mà nó có thể tìm thấy.

Nếu DCDIAG báo cáo có vấn đề nào đó, bạn cần phải sửa các vấn đề này bằng cách chỉ định tiếp lệnh /FIX. Mặc dù tiếp lệnh này rất đơn giản vì nó không yêu cầu bạn cung cấp bất cứ thuộc tính bổ sung nào, nhưng có một số thứ khá quan trọng cần biết về cách sử dụng nó.

Trước khi có thể sử dụng tiếp lệnh /FIX, cần nhớ những gì đang thực hiện. Bạn đang lệnh cho một tiện ích tự động tiến hành các thay đổi đối với domain controller của mình, điều có nghĩa rằng đang thay đổi một cách mò mẫm Active Directory. Domain Controller Diagnostic Utility được thiết kế để khi sử dụng tiếp lệnh /FIX, nó sẽ chỉ thực hiện việc sửa chữa và cứ tưởng rằng điều đó là an toàn. Tuy nhiên, hành động sử dụng tiếp lệnh này có liên quan đến việc tạo các thay đổi đến domain controller làm cho chúng tôi phải nhắc nhở các bạn phải cực kỳ thận trọng. Tiếp lệnh này được thiết kế với mục đích an toàn, tuy nhiên bất cứ lúc nào làm việc với những vấn đề phức tạp như domain controller thì diễn biến của nó hoàn toàn không phải lúc nào cũng vậy.

Đề phòng trường hợp đó, chúng tôi khuyên các bạn không nên sử dụng tiếp lệnh /FIX khi mới sử dụng DCDIAG mà thay vào đó nên chạy các test của mình, cần phải bỏ ra thời gian để đánh giá các kết quả thu được trước khi sử dụng tiếp lệnh /FIX. Nếu quyết định sử dụng tiếp lệnh nguy hiểm này, chúng tôi khuyên các bạn hãy thực hiện một backup đầy đủ cho domain controller mục tiêu trước khi thực hiện.

Nếu bạn là người muốn vượt rào, hãy đề phòng trước cho việc thực hiện sửa domain controller là cài đặt Windows trên một máy tính dự phòng, sau đó cấu hình máy tính đó hoạt động như một domain controller. Khi thực hiện xong công việc đó, bạn hãy đợi cho đến khi quá trình tạo bản sao hoàn tất, sau đó hãy tiến hành các thử nghiệm của mình. Bằng cách đó bạn có thể xây dựng lại Active Directory nếu có vấn đề gì đó không  hay đối với tiến trình sửa chữa.

/TEST

Tiếp lệnh cuối cùng mà chúng tôi muốn giới thiệu cho các bạn đó là /TEST. Cho tới đây, hầu hết các tiếp lệnh dòng lệnh mà chúng tôi giới thiệu thiên về việc điều khiển Domain Controller Diagnostic Utility hành động khi chạy các test khác nhau. Bạn có thể thấy rằng Domain Controller Diagnostic Utility chạy một tập các test mặc định, nhưng cũng có thể sử dụng cả tiếp lệnh /C hoặc tiếp lệnh /SKIP để chạy các test bổ sung tương ứng.

Điểm mà chúng tôi muốn giới thiệu cho các bạn đến lúc này nằm trong giả định rằng bạn sẽ chạy nhiều test.  Khi đó tiếp lệnh /TEST sẽ chỉ định một cách đơn giản tên của test mà bạn muốn chạy. Sau đó chỉ cần nối thêm dấu hai chấm và tên của test vào sau tiếp lệnh này.
Cần lưu ý rằng, không thể sử dụng tiếp lệnh /TEST để chạy nhiều test. Như những gì bạn có thể hình dung, tiếp lệnh /TEST không thể tương thích với tiếp lệnh /SKIP vì hai tiếp lệnh lại mâu thuẫn nhau.

Kết luận

Trong bài này chúng tôi đã giới thiệu một số chuyển tiếp lệnh để các bạn có thể sử dụng với Domain Controller Diagnostic Utility. Trong phần tiếp theo của loạt bài này, chúng tôi sẽ tập trung về các bài test riêng biệt mà các bạn có thể tự thực hiện.

Các bộ điều khiển miền - Domain Controller - chính là phần xương sống đối với bất kỳ một mạng sử dụng hệ điều hành Windows nào. Chính vì lẽ đó nên nếu các bộ điều khiển miền của bạn không làm việc thì Active Directory cũng sẽ không làm việc. Nếu Active Directory không làm việc thì người dùng không thể đăng nhập, các chính sách nhóm sẽ không được thực thi và toàn bộ các tính năng khác cũng không có sẵn. May thay, Windows có đi kèm một công cụ mà bạn có thể sử dụng nhằm giữ cho các bộ điều khiển miền của mình chạy một cách êm ái. Công cụ này được gọi là công cụ chuẩn đoán Domain Controller. Trong bài viết này, chúng tôi sẽ giới thiệu cho các bạn cách sử dụng công cụ  này để thực hiện một số hành động bảo trì cơ bản và chuẩn đoán về các bộ điều khiển miền.

Trước khi bắt đầu

Công cụ chuẩn đoán Domain Controller hiện là một phần của Windows. Với mục đích của bài viết này, chúng tôi chỉ làm việc với phiên bản của tiện ích này có trong Windows Server 2008. Tuy nhiên hầu hết nhưng không phải là tất cả các tính năng mà chúng tôi sẽ nói về đều có sẵn trong Windows Server 2003 SP1. DCDIAG  đã tồn tại trước Windows Server 2003 SP1 nhưng nhiều lệnh ngày nay sử dụng đã được giới thiệu trong phiên bản Windows Server 2003 SP1 này.

Bạn có thể truy cập vào công cụ chuẩn đoán Domain Controller bằng cách chạy lệnh DCDIAG từ nhắc lệnh của Windows.

Chạy công cụ chuẩn đoán Domain Controller

Nếu bạn muốn giữ đơn giản hóa mọi thứ, hãy chạy công cụ này bằng cách nhập vào lệnh DCDIAG trong cửa sổ nhắc lệnh của Windows. Bằng cách thực hiện như vậy, tiện ích sẽ thực hiện một loạt các kiểm tra đối với Domain Controller mà bạn được kết nối với. Bạn có thể xem ví dụ về những gì được test trong hình A bên dưới.

Hình A: Công cụ chuẩn đoán Domain Controller chạy một số kiểm tra đối với Domain Controller.

Bằng cách nhập vào lệnh DCDIAG quả thực rất đơn giản nhưng thực sự chưa có một bài viết nào giới thiệu cụ thể về các lệnh này. Bên cạnh đó còn có nhiều vấn đề bạn có thể thực hiện với công cụ này. Trước khi có thể đánh giá cao tất cả các tính năng của công cụ này, bạn cần phải thân thiện với các tham số mang tính tùy chọn để sử dụng kết hợp với lệnh DCDIAG. Nếu quan sát vào hình B, bạn có thể thấy được rằng cú pháp của lệnh DCDIAG là quá dài. Giống như hầu hết các lệnh bị phức tạp hóa, nhưng cú pháp của lệnh này lại không tồi như xuất hiện ban đầu của nó. Khi bạn hiểu được cách làm việc của lệnh này, việc sử dụng nó sẽ trở nên đơn giản hơn rẩt nhiều.

Hình B: Cú pháp lệnh DCDIAG rất dài

Ngắt giữa cú pháp lệnh

Như những gì bạn thấy trong hình ở trên, cú pháp cơ bản của lệnh DCDIAG sẽ như sau:

dcdiag.exe /s:<Directory Server>[:<LDAP Port>] [/u:<Domain>\<Username>
/p:*|<Password>|""]
           [/hqv] [/n:<Naming Context>] [/f:<Log>] [/x:XMLLog.xml]
           [/skip:<Test>] [/test:<Test>]

Mặc dù capture màn hình thể hiện trong hình B đã liệt kê những gì một tiếp lệnh thực hiện, nhưng vẫn cần một sự giải thích rõ hơn về chúng. Dưới đây là một số những thông tin chi tiết về các tiếp lệnh này.

/H

Nếu bạn chạy lệnh DCDIAG với tham số /H, nó sẽ hiển thị cú pháp của lệnh này theo như cách thể hiện trong hình B. Nếu quan sát vào hình trên, bạn sẽ thấy rằng bạn cũng có thể sử dụng tiếp lệnh /? để hiển thị cú pháp của lệnh.

/S

Tham số /S cho phép bạn chỉ định một máy chủ (máy chủ này là home server). Về bản chất thì điều này có nghĩa là bạn có thể sử dụng tham số này để chỉ định tên cho Domain Controller mà bạn muốn chạy lệnh DCDIAG với nó. Tuy nhiên trong bài khi chúng tôi chạy lệnh DCDIAG trong hình A, chúng tôi đã không chỉ định máy chủ home server. Nếu bạn không chỉ định home server, khi đó lệnh DCDIAG sẽ tự động chọn ra một máy chủ nào đó.

Có một số ví dụ về vấn đề home server chỉ định sẽ bị bỏ qua. DCPROMO và các bài test Register In DNS được chạy nội bộ thay cho chạy trên một điều khiển miền. Chính vì vậy, nếu bạn muốn chỉ định một home server cho các bài test này, nó sẽ bị bỏ qua. Chúng tôi sẽ nói thêm về vấn đề này trong các phần tiếp theo.

/N

Tham số /N cho phép bạn chỉ định một ngữ cảnh tên miền. Trong trường hợp bạn chưa quen với thuật ngữ này, thì cần phải biết được rằng, mọi miền được hiện diện bởi một ngữ cảnh tên miền. Ngữ cảnh tên miền lưu các đối tượng cho miền, các đối tượng ở đây chẳng hạn như người dùng, máy tính, các nhóm,…. Bạn không cần phải chỉ định ngữ cảnh tên miền, nhưng nếu bạn chọn sử dụng một ngữ cảnh thì bạn có thể vào nó là NetBIOS, DNS hoặc biểu mẫu tên miền phân biệt DN.

/U

Trừ khi bạn được đăng nhập như một quản trị viên của miền kiểm tra, bằng không bạn sẽ phải sử dụng lệnh DCDIAG với một số các tiêu chuẩn quản trị. Các tiêu chuẩn quản trị ở đây điển hình vẫn là username và password. Tiếp lệnh /U được sử dụng để chỉ định username. Do bạn đang nhập vào tê của tài khoản với các điều khoản quản trị miền nên bạn sẽ phải nhập vào username theo định dạng domain\username.

/P

Tiếp lệnh khác được sử dụng khi nhập một tập các tiêu chuẩn là tiếp lệnh /P. Theo sau tiếp lệnh này sẽ là một mật khẩu của tài khoản mà bạn đã chỉ định thông qua tiếp lệnh /U.

/A

Active Directory thường được nhóm vào trong các site. Một site điển hình sẽ trưng diện một bộ sưu tập các bộ điều khiển miền có khả năng tin cậy và kết nối tốc độ cao giữa chúng. Cho ví dụ, nếu một tổ chức có hai site khác nhau được kết nối cùng với nhau bởi một liên kết WAN, mỗi một trong các site này sẽ được cấu hình để thực hiện như một site riêng do các máy tính bên trong chúng đều nằm trong một LAN, tuy nhiên không có kết nối LAN giữa các site này.

Nếu tổ chức của bạn được chia thành các site thì bạn sẽ cảm thấy hữu ích đối với tiếp lệnh này. Sử dụng tiếp lệnh này để chỉ thị DCDIAG kiểm tra tất cả các bộ điều khiển miền trong site hiện hành.

/E

Tiếp lệnh The /E cũng giống như tiếp lệnh /E, ngoại từ thay vì việc chỉ thị cho DCDIAG kiểm tra tất cả các bộ điều khiển miền trong site hiện hành, nó chỉ thị cho DCDIAG kiểm tra bộ điều khiển miền trong toàn bộ doanh nghiệp.

/Q

Như những gì bạn có thể thấy, đầu ra của lệnh DCDIAG khá dài. Chính vì vậy bạn rất dễ bị mất các thông báo lỗi trong màn hình đầu ra dài như vậy. Nếu điều đó xảy ra với bạn, bạn có thể sử dụng tiếp lệnh /Q để chạy DCDIAG trong chế độ “Quiet”, chế độ sẽ chỉ liệt kê các thông báo lỗi.

/V

Tiếp lệnh /V là kiểu tiếp lệnh ngược với tiếp lệnh /Q. Trong khi tiếp lệnh /Q giảm kích thước của đầu ra thì tiếp lệnh này lại tăng kích thước đầu ra lên. Theo cách đó bạn có thể biết thêm các thông tin chi tiết về vấn đề mà mình đang muốn khắc phục.

/I

Đôi khi DCDIAG sẽ sinh ra các thông báo lỗi vô nghĩa gây lộn xộn cho những quản trị viên chưa có nhiều kinh nghiệm. Nếu điều đó xảy ra với bạn, bạn có thể sử dụng tiếp lệnh /I để chỉ thị cho DCDIAG bỏ đi các thông báo lỗi không quan trọng.

Kết luận

Trong phần một này chúng tôi đã giới thiệu cho các bạn về một số lệnh cơ bản được sử dụng bởi công cụ chuẩn đoán Domain Controller. Trong phần 2 của loạt bài này, chúng tôi sẽ tiếp tục giới thiệu về cách sử dụng các tiếp lệnh khác và cách chỉ định các bài test cụ thể mà bạn có thể muốn thực hiện.