Phần 28: Quản lý các nâng cấp phần mềm

Khi triển khai Windows vào các máy tính mục tiêu, ai cũng muốn các máy tính đó sẽ được vá đầy đủ sau khi triển khai để có được an toàn ngay từ đầu. Tuy nhiên đây là một vấn đề khó khăn vì các nâng cấp bảo mật và một số nâng cấp khác được Microsoft phát hành thường xuyên cho các sản phẩm của họ. May mắn ở chỗ là bạn có thể sử dụng Windows Server Update Services (WSUS) để quản lý sự phân phối của các nâng cấp phần mềm như vậy trong quá trình triển khai LTI cũng như sau đó. Trong phần này chúng tôi sẽ giới thiệu cho các bạn cách cài đặt và cấu hình WSUS và cách hợp nhất WSUS vào cơ sở hạ tầng triển khai MDT 2010 của bạn.

Sử dụng WSUS trong môi trường xây dựng và sản xuất

Bạn nên sử dụng WSUS trong cả hai môi trường triển khai MDT của mình: xây dựng và sản xuất. Môi trường xây dựng của bạn là một phòng lab biệt lập, nơi bạn sẽ triển khai và capture các image của các máy tính tham chiếu và sau đó tiến hành triển khai thử các image đã được capture vào các kiểu máy tính khác nhau trong môi trường sản xuất. Sử dụng WSUS trong môi trường xây dựng cho phép các image tham chiếu của bạn được cập nhật kịp thời các bản vá tại thời điểm tạo image. Nếu bạn không vá các image tham chiếu giống như vậy, các triển khai sản phẩm của bạn sẽ mất rất nhiều thời gian vì trong quá trình triển khai bạn sẽ phải cần đến tất cả các nâng cấp có sẵn này.  

Việc thử và giữ cho các image tham chiếu của bạn luôn cập nhật đầy đủ và kịp thời các bản vá sau khi được capture là một việc mất rất nhiều thời gian và có thể nói là vụn vặt. Bạn có thể sử dụng DISM cho mục đích này, tuy nhiên nó vẫn cần bạn phải bỏ thời gian và nỗ lực để thực hiện (xem trong phần 2 của loạt bài này để biết cách sử dụng DISM). Kết quả là, bạn chắc chắn sẽ muốn sử dụng WSUS trong môi trường sản xuất để các bản vá đó được áp dụng cho các máy tính mục tiêu khi chúng được triển khai bằng MDT. Theo cách đó, bất cứ bản vá gì không hiện diện trong image sẽ được áp dụng trong suốt quá trình triển khai để khi triển khai kết thúc, các máy tính sẽ được vá đầy đủ và an toàn. Một phương pháp khác bạn có thể thực hiện là sử dụng MDT để tạo lại tất cả các image tham chiếu mỗi khi có nâng cấp phần mềm mới được phát hành bởi Microsoft. Nếu bạn chỉ có một vài image tham chiếu thì đây có thể được cho là phương pháp tốt nhất nên thực hiện. Trong trường hợp đó bạn chỉ cần sử dụng WSUS trong môi trường xây dựng, không cần sử dụng trong môi trường sản xuất. Tuy nhiên dù có sử dụng cách nào đi chăng nữa thì các bạn cũng vẫn cần phải thực hiện các bước cài đặt và cấu hình WSUS và cấu hình MDT để sử dụng WSUS cho cả hai môi trường triển khai dưới đây.

Cài đặt WSUS

Trên nền tảng Windows Server 2008 R2, WSUS có sẵn dưới một server role có thể cài đặt. Với các nền tảng Windows Server trước đó, bạn phải download WSUS từ Microsoft Download Center. Trong hướng dẫn này, chúng ta sẽ thực hiện cài đặt WSUS role trên một máy chủ thành viên mang tên SEA-MDT-01 trong miền CONTOSO, đây cũng là máy chủ mà chúng đã sử dụng dưới danh nghĩa MDT 2010 server xuyên suốt loạt bài này. Trước khi cài đặt WSUS, bạn cần cài đặt cơ sở dữ liệu cho dịch vụ. Có thể là Microsoft SQL Server 2008 Express, Standard hoặc Enterprise Edition của SQL Server 2005 SP2 hoặc SQL Server 2008. Nếu không có cơ sở dữ liệu SQL Server hoặc SQL Server Express, WSUS sẽ tự động cài đặt Windows Internal Database mức tối thiểu để sử dụng. Do chúng ta sẽ cài đặt WSUS role trên MDT server SEA-MDT-01 của mình, máy chủ đã cài đặt SQL Server 2008 Express SP1 để hosting cơ sở dữ liệu MDT, và cũng sẽ sử dụng cơ sở dữ liệu đang tồn tại trong cài đặt WSUS của mình. Xem phần 15 trong loạt bài này để có thêm thông tin chi tiết về cách chúng ta đã cài đặt SQL Server Express trên MDT server của mình như thế nào.

Bắt đầu bằng cách khởi chạy Add Roles wizard từ cửa sổ chương trình oobe.exe hoặc Server Manager, sau đó chọn WSUS role ở phía dưới trong danh sách các role có sẵn (quá trình thực hiện cũng tự động cài đặt Web Server role trên máy chủ của bạn):

Hình 1: Bước 1 trong quá trình cài đặt WSUS server role

Bắt đầu WSUS Setup wizard bằng cách chọn location nơi chứa các nâng cấp được download trên máy chủ (trong hướng dẫn này chúng ta sẽ sử dụng phần vùng U để lưu trữ các nâng cấp này):

Hình 2: Bước 2 trong quá trình cài đặt WSUS server role

Chọn instance cơ sở dữ liệu SQL Server Express đã được cài đặt trên máy chủ:

Hình 3: Bước 3 trong quá trình cài đặt WSUS server role

Cửa sổ tiếp theo sẽ hiển thị rằng WSUS Setup wizard đã kết nối thành công với SQL server instance SQLEXPRESS:

Hình 4: Bước 4 trong quá trình cài đặt WSUS server role

Chúng ta sẽ sử dụng Default Web Site cho WSUS role:

Hình 5: Bước 5 trong quá trình cài đặt WSUS server role

Kích Next trên trang xác nhận để kết thúc việc cài đặt WSUS:

Hình 6: Bước 6 trong quá trình cài đặt WSUS server role

Cấu hình WSUS

Khi WSUS kết thúc việc cài đặt trên máy chủ của bạn, WSUS Configuration wizard sẽ tự động khởi chạy:

Hình 7: Bước 7 trong quá trình cài đặt WSUS server role

Kích Next và gia nhập Microsoft Update Improvement Program nếu muốn:

Hình 8: Bước 1 trong quá trình cấu hình WSUS server role

Cấu hình mặc định là cho WSUS có thể download các nâng cấp từ Microsoft Update (MU) website:

Hình 9: Bước 9 trong quá trình cấu hình WSUS server role

Các công ty lớn có thể thiết lập một kiến trúc các máy chủ WSUS để các máy chủ tại các văn phòng chi nhánh sẽ thu được các nâng cấp của chúng từ máy chủ tại trụ sở, máy chủ thu được các nâng cấp từ MU.

Tiếp theo, chỉ định proxy server nếu có:

Hình 10: Bước 3 trong quá trình cấu hình WSUS server role

Kích nút proxy server để kết nối WSUS server của bạn với máy chủ “thượng nguồn”, trong trường hợp này sẽ là MU website:

Hình 11: Bước 4 trong quá trình cấu hình WSUS server role

Chọn ngôn ngữ cho các nâng cấp mà bạn sẽ download:

Hình 12: Bước 5 trong quá trình cấu hình WSUS server role

Chỉ chọn các sản phẩm của Microsoft cho những thứ mà bạn muốn sử dụng các nâng cấp trong suốt quá trình cài đặt. Trong hướng dẫn này, chúng tôi chỉ download các nâng cấp cho Windows 7:

Hình 13: Bước 6 trong quá trình cấu hình WSUS server role

Mặc định tất cả các nâng cấp quan trọng và bảo mật sẽ được download, cộng thêm vào đó là các nâng cấp định nghĩa sử dụng cho bản thân WSUS:

Hình 14: Bước 7 trong quá trình cấu hình WSUS server role

Nếu muốn bạn có thể download các kiểu nâng cấp khác để cài đặt trong quá trình triển khai. Một lựa chọn tốt ở đây sẽ là hai mục cuối trong danh sách ở trên, Update Rollups và Updates.

Cửa sổ tiếp theo sẽ chỉ thị rằng cấu hình mặc định cho phép bạn đồng bộ WSUS một cách thủ công nếu muốn:

Hình 15: Bước 8 trong quá trình cấu hình WSUS server role

Nếu muốn, bạn có thể thay đổi tùy chọn trong cửa sổ trước để WSUS có thể đồng bộ theo lịch biểu, cho ví dụ như vào lúc 2 giờ sáng hàng ngày.

Cửa sổ tiếp theo được cấu hình mặc định để thực hiện đồng bộ hóa ngay lập tức, tuy nhiên chúng ta sẽ hủy chọn hộp kiểm để có thể thực hiện cấu hình xa hơn:

Hình 16: Bước 9 trong quá trình cấu hình WSUS server role

Khi wizard kết thúc, mở giao diện quản trị WSUS từ Administrative Tools và chọn Options:

Hình 17: Bước 10 trong quá trình cấu hình WSUS server role

Kích liên kết Automatic Approvals phía bên trái của cửa sổ ở trên để mở hộp thoại Automatic Approvals:

Hình 18: Bước 11 trong quá trình cấu hình WSUS server role

Kích nút Edit để chỉnh sửa Default Automatic Approval Rule:

Hình 19: Bước 12 trong quá trình cấu hình WSUS server role

Kích siêu liên kết đầu tiên trong hộp Step 2. Khi đó bạn sẽ thấy xuất hiện một hộp thoại mới, hộp thoại này cho phép bạn có thể chọn các nâng cấp nào được cho phép tự động để bạn không phải tự mình cho phép chúng. Automatic Approval sẽ là một lựa chọn tốt nhất cho các tổ chức không có đủ nhân viên CNTT để có thể thẩm định và test các nâng cấp được phát hành với ma trận tất cả các ứng dụng đã được cài đặt (trong thực tế điều này xảy ra với hầu hết các tổ chức). Mặc định, chỉ các nâng cấp quan trọng và nâng cấp bảo mật được cho phép tự động:

Hình 20: Bước 13 trong quá trình cấu hình WSUS server role

Nếu bạn đã cấu hình WSUS trước để download Update Rollups và Updates, chắc chắn bạn cũng sẽ muốn chọn hai hộp kiểm cuối cùng trong hộp thoại ở trên. Kích OK để trở về hộp thoại Automatic Approvals, và chọn hộp kiểm được chỉ thị để kích hoạt rule tự động cho phép các kiểu nâng cấp mà bạn đã chỉ định:

Hình 21: Bước 14 trong quá trình cấu hình WSUS server role

Kích OK để kết thúc việc cấu hình WSUS.

Đồng bộ WSUS

Trong bước tiếp theo để đồng bộ WSUS server của mình với máy chủ thượng nguồn (upstream), trong trường hợp này là MU website. Trong giao diện quản lý WSUS, kích phải vào nút Synchronization và chọn Synchronize Now: 

Hình 22: Đồng bộ WSUS

Khi quá trình đồng bộ hoàn tất, bạn sẽ thấy kết quả trong panel chi tiết của giao diện điều khiển:

Hình 23: Kết quả đồng bộ WSUS

Lưu ý rằng "Succeeded" không có nghĩa tất cả các nâng cấp đều được download. Do WSUS sử dụng BITS để download các nâng cấp trong chế độ background nên quá trình này có thể diễn ra khá lâu. Để kiểm tra tiến trình download các nâng cấp, chọn nút All Updates bên dưới Updates. Bất cứ nâng cấp nào có biểu tượng trong cột đầu tiên giống như hai mục bên dưới trong hình bên dưới là vẫn đang được download từ MU và chưa sẵn sàng cho triển khai:

Hình 24: Các nâng cấp được download và được cho phép

Bằng cách chọn nút Updates, bạn có thể nhận được một bức tranh về các hạng mục các nâng cấp khác nhau:

Hình 25: Tổng quan về các nâng cấp

Bạn có thể xem các thông tin bổ sung từ nút Reports nếu muốn:

Hình 26: Tạo báo cáo

Tại điểm này, WSUS đã được cấu hình và các nâng cấp cho Windows 7 đã được download.

Cấu hình MDT để sử dụng WSUS

Giờ đây chúng ta cần cấu hình MDT để các máy tính mục tiêu của mình có thể kéo về các nâng cấp từ WSUS trong quá trình triển khai LTI. Mở Deployment Workbench và chọn chuỗi nhiệm vụ cho triển khai xây dựng hoặc sản xuất, phụ thuộc vào môi trường nào bạn đang làm việc. Mở thuộc tính của chuỗi nhiệm vụ và chọn tab Task Sequence. Chọn nhiệm vụ Windows Update (Pre-Application Installation) bên trong nhóm nhiệm vụ State Restore, trên tab Options cho nhiệm vụ này, xóa hộp kiểm được chỉ thị bên dưới để kích hoạt việc sử dụng WU (hoặc WSUS trong trường hợp này) để vá máy tính mục tiêu trong quá trình triển khai:

Hình 27: Cấu hình chuỗi nhiệm vụ để sử dụng WSUS

Áp dụng thay đổi, sau đó thực hiện tương tự với nhiệm vụ Windows Update (Post-Application Installation), sau đó đóng thuộc tính chuỗi nhiệm vụ.

Mở file CustomSettings.ini cho deployment share của bạn và thêm dòng dưới đây vào phần [Default]:

WSUSServer=http://SEA-MDT-01

Lệnh này sẽ chỉ thị cho các máy tính mục tiêu máy chủ để kéo về các nâng cấp trong quá trình triển khai:

Hình 28: Cấu hình CustomSettings.ini để các máy tính mục tiêu sẽ sử dụng WSUS trong quá trình cài đặt

Kích OK để áp dụng các thay đổi và tất cả mọi thứ đến đây gần như là xong. Lúc này bạn hãy sử dụng MDT để triển khai Windows 7 vào một máy tính mục tiêu, sau khi triển khai kết thúc, mở Programs and Features từ Control Panel, kích liên kết View Installed Updates phía bên trái, bạn sẽ thấy một bó các file nâng cấp đã được cài đặt trên máy tính trong quá trình triển khai:

Hình 29: Các nâng cấp được cài đặt trên máy tính mục tiêu trong quá trình triển khai LTI

Kết luận

Trong phần tiếp theo của loạt bài này, chúng tôi sẽ bổ sung thêm Windows Deployment Services vào kiến trúc triển khai MTI.

  (Theo Quan Tri Mang)

Phần 27: Các mẹo quản lý driver

Trong một số phần trước của loạt bài này, chúng ta đã cùng nhau tìm hiểu hai phương pháp ("để Windows quyết định" và "để bạn quyết định") mà bạn có thể sử dụng để quản lý các driver khi thực hiện triển khai Lite Touch bằng MDT 2010. Trong phần này chúng tôi sẽ kết thúc loạt bài về quản lý driver này với một số mẹo và một câu chuyện. Đầu tiên là câu chuyện, được đệ trình nên bởi một độc giả có tên Tim Lors và câu chuyện này có thể minh chứng cho những khó khăn mà bạn có thể gặp phải khi quản lý các driver trong quá trình triển khai:

“Cách đây hơn một năm, tôi đã viết một số kịch bản để cài đặt driver trên các máy tính WinXP. Tuy nhiên vấn đề mà tôi mắc phải là chọn driver không đúng (hay không liên quan) với hệ điều hành. Nó là một lỗi thuộc về nhà sản xuất trong việc thực thi PnP (Plug and Play) đúng cách giữa file driver inf của họ và phần cứng. Đặc biệt, file inf đã chỉ thị nó là driver tốt nhất cho một phần cứng nào đó trong khi đó sự thật lại không thể làm việc với hóa thân phần cứng đó. Chỉ có một phương pháp có thể cài đặt đúng driver trong các trường hợp như vậy là so sánh PnP ID của phần cứng với danh sách các driver có vấn đề, và nếu phát hiện ra một sự tương ứng thì chúng ta sẽ phải chọn một cách thủ công driver thích hợp dựa trên chứng chỉ phụ - thường là số model của máy tính. Chứng chỉ phụ chung nhất cần cho sự lựa chọn “để bạn chọn” là số model của máy tính, đôi khi cũng có thể là phiên bản BIOS hoặc PnP subset ID và trong trường hợp hiếm đó là lỗi và thử nghiệm”. Rõ ràng lỗi và thử nghiệm thường khó xảy ra vì khi Windows đã cài đặt driver gì thì nó đã tin tưởng đó là sự lựa chọn tốt nhất, và lúc này nhiệm vụ của bạn là phải cách ly driver “không làm việc” đó ra khỏi Windows, hoặc là Windows sẽ cài đặt lại driver đó. Lưu ý rằng kịch bản này đã xuất hiện trong môi trường gần 10.000 máy tính với hơn 25 model khác nhau.”

Hầu hết các chuyên gia CNTT đều cho rằng driver là một trong những vấn đề gây đau đầu nhất đối với họ, câu chuyện ở trên chỉ nhằm mục đích nói rõ hơn vấn đề mà chúng tôi đề cập đến trong phần này. Bốn phần gần đây nhất trong loạt bài đều được giới thiệu về chủ đề này, và trong phần này, chúng tôi sẽ kết thúc vấn đề thảo luận về driver bằng một số mẹo giúp đơn giản hóa mọi thứ.

Tìm kiếm driver

Khó khăn đầu tiên là tìm driver (out-of-box) cho các hệ thống của bạn. Một số hãng cho phép bạn tìm thấy các driver khá dễ dàng, Dell là một ví dụ trong số đó, hãng này cung cấp driver cho mỗi một hệ thống desktop bằng một file .cab cho mỗi hệ điều hành. Để download các file .cab này, người dùng có thể truy cập vào địa chỉ www.delltechcenter.com và trong menu thanh cuộn phía trái, chọn Home, Microsoft, Microsoft System Center, SCCM – System Center Configuration Manager, Dell Business Client Operating System Deployment, Dell Business Client Operating System Deployment – The .CAB Files, khi đó bạn sẽ thấy những gì thể hiện như hình 1 bên dưới:

Hình 1: Download drvier cho các hệ thống máy khách của Dell dưới các file .cab

Khi download một file .cab, bạn có thể bung nó vào một thư mục, sau đó trỏ đến thư mục này khi import driver vào deployment share của bạn.

Các hãng khác cũng có các công cụ để download driver, tuy nhiên theo quan điểm của tôi, hầu như đều không đơn giản và hữu dụng như cách mà Dell thực hiện. Đây là một số ví dụ về các công cụ này và nơi tìm chúng:

• HP SoftPaq Download Manager
• Lenovo Update Retriever

Bung các file INF từ các file EXE

Đôi khi một hãng phần cứng nào đó có thể cung cấp driver cho một thiết bị của họ dưới dạng file .exe thay vì file .cab. Trong trường hợp này, công cụ có thể giải quyết được vấn đề của bạn chính là WinRAR, nó cho phép bạn có thể bung các file driver từ .exe vào một thư mục.  Cần nhớ rằng, để import một driver nào đó, MDT cần phải có file .inf và các file có liên quan cho driver – không thể import file .exe.

Ngăn chặn sự tiêm nhiễm driver

Để ngăn chặn một driver nào đó mà bạn đã import khỏi bị tiêm nhiễm (cho ví dụ trong quá trình test bạn đã phát hiện ra rằng driver gây ra vấn đề khi cài đặt), bạn chỉ cần mở cửa sổ properties của driver và bỏ chọn hộp kiểm Enable This Driver (hình 2).

Hình 2: Bạn có thể kích hoạt hoặc vô hiệu hóa driver để cho phép hoặc ngăn chặn sự tiêm nhiễm driver

Lưu ý rằng, driver ở trên được thiết kế cho cả Windows 32-bit và 64-bit. Nếu bạn xác định được rằng nó không làm việc như dự định cho Windows 64-bit, bạn có thể vẫn để driver đó được kích hoạt nhưng hủy chọn hộp kiểm x64 để tránh bị tiêm nhiễm trong qua trình triển khai Windows 64-bit.

Nếu mong muốn bạn thậm chí có thể vô hiệu hóa tất cả driver trong một thư mục nào đó bằng cách vô hiệu hóa thư mục (hình 3):

Hình 3: Bạn có thể vô hiệu hóa một thư mục tùy chỉnh nào đó trong deployment share của mình

Quản lý Boot Driver bằng Selection Profiles

Bạn cũng có thể sử dụng selection profiles để quản lý driver trong giai đoạn khởi động Windows PE của triển khai LTI. Để thực hiện điều này, mở thuộc tính của deployment share và chọn tab Windows PE x64 Components hoặc Windows PE x86 Components để quản lý driver cho kiến trúc hệ điều hành mà bạn đang triển khai (hình 4):

Hình 4: Quản lý driver trong quá trình khởi động của triển khai LTI

Mặc định, selection profile All Drivers And Packages được chọn ở đây, tuy nhiên chỉ các driver mạng và mass storage từ selection profile này được tích hợp trong image khởi động Windows PE. Nếu cần thiết, bạn có thể tọ một selection profile tùy chỉnh có chứa driver WinPE của một phần cứng cụ thể nào đó cho các máy tính mục tiêu của bạn.

Sử dụng nhiều nhóm Driver Group để triển khai theo Model và nhà sản xuất

Trong phần trước của loạt bài này, chúng ta đã biết cách định nghĩa một nhóm driver lẻ mang tên DriverGroup001 và sử dụng nó để quản lý driver khi triển khai bằng model và nhà sản xuất cho các máy tính mục tiêu. Keith Garner, một chuyên gia triển khai của Xtreme Consulting Group, đã có một bài viết khá thú vị mở rộng về chủ đề này bằng cách giới thiệu cách tổ chức driver một cách hiệu quả hơn và sau đó sử dụng một vài nhóm driver để điều khiển cách chúng được tiêm nhiễm trong quá trình cài đặt như thế nào. Mọi chi tiết về bài viết, các bạn có thể xem tại đây.

Một post khá hay khác mà các bạn có thể đọc là về việc sử dụng các model alias của Michael Murgolo, một cố vấn quan trọng của Microsoft Consulting Services.  

Bổ sung thêm driver vào Image

Bạn có thể sử dụng lệnh DISM.exe để bổ sung thêm driver vào một offline image, chỉ cần gắn image và sử dụng DISM với tùy chọn /add-driver (bạn có thể xem lại trong phần 2 của loạt bài này để biết được các sử dụng DISM.exe).

Để bổ sung driver vào kho lưu trữ driver (cung cấp sẵn các driver để Windows có thể phát hiện thiết bị được gắn cần driver nào), bạn có thể sử dụng lệnh PnPutil.exe. Đây là một cách làm rất hữu dụng, cho ví dụ nếu bạn đã sử dụng Microsoft Update Catalog để download file .cab chứa các driver cho một máy in và muốn cung cấp sẵn các driver này trong máy tính tham chiếu của mình để khi triển khai thì các driver này đã hoàn toàn có sẵn cho việc cài đặt.

Duy trì cấu hình driver khi capture một Windows Image

Cuối cùng, nếu muốn capture một image tham chiếu và tiển khai vào một phần cứng tương tự, bạn có thể cung cấp cho người dùng một trải nghiệm khởi động nhanh hơn bằng cách cấu hình thiết lập PersistAllDeviceInstalls trong file answer của mình để sysprep máy tính tham chiếu.

  (Theo Windowsnetworking)

Phần 26: Quản lý Driver theo model và nhà sản xuất

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 cách sử dụng MDT 2010 để quản lý driver (out-of-box) cần thiết cho triển khai Lite Touch. Chúng ta đã biết tại sao driver lại làm phức tạp hóa quá trình triển khai và đã biết hai phương pháp cho việc quản lý driver:

• Phương pháp “để Windows quyết định” là phương pháp mà bạn sẽ nhập vào tất cả các driver (out-of-box) vào thư mục Out-of-Box Drivers trong deployment share, sau đó cho phép bảng liệt kê PnP trên máy tính mục tiêu quyết định driver nào cần được download từ deployment share và sau đó được cài đặt.
   
• Phương pháp “để bạn quyết định” là phương pháp mà ở đó bạn sẽ tự kiểm soát driver nào được cài đặt bằng cách tạo một cấu trúc thư mục có thức bậc bên trong deployment share để chứa driver cần thiết cho mỗi kịch bản triển khai.

Phương pháp “để Windows quyết định” có ưu điểm ở chỗ đơn giản, tuy nhiên để thực hiện nó, bạn cần phải xây dựng một quá trình triển khai thử nghiệm cho các kiểu model và nhà sản xuất trong môi trường sản xuất của mình. Sau mỗi lần thêm một driver mới vào thư mục Out-of-Box Drivers của deployment share, bạn cần test lại quá trình triển khai cho mỗi một model và nhà sản xuất để bảo đảm rằng driver mới không gây ra vấn đề gì với phần cứng đang tồn tại. Vì vậy phương pháp này có thể dễ dàng trong thiết lập nhưng có thể rất mất công trong việc bảo trì với những gì sẽ diễn ra.

Phương pháp “để bạn quyết định” lại rất cần nhiều công việc cho việc thiết lập, đặc biệt nếu bạn tạo một cấu trúc thư mục phức tạp và sử dụng rất nhiều profile chọn lọc cũng như chuỗi nhiệm vụ để quản lý driver được triển khai cho các máy tính mục tiêu. Mặc dù vậy khi đã thiết lập xong, phương pháp này sẽ trở nên đơn giản trong việc duy trì lâu dài vì nó loại trừ được nhiều vấn đề có thể xuất hiện khi máy tính cài đặt phải một driver sai.

Có một biến thể của phương pháp “để bạn quyết định” có thể làm cho việc quản lý driver cho các triển khai của bạn trở nên đơn giản hơn. Biến thể này có liên quan đến việc sử dụng các nhóm driver thay vì các profile chọn lọc, và đó là những gì chúng tôi sẽ giới thiệu cho các bạn trong phần này.

Chèn driver bởi model và nhà sản xuất

Trong phiên bản trước của MDT 2008, bạn có thể sử dụng nhóm driver để tổ chức một cách logic các driver out-of-box mà bạn import vào deployment share của mình. Cho ví dụ, bạn có thể tạo một nhóm driver cho driver ổ lưu trữ và một nhóm khác cho Windows PE image,... Sau đó bạn liên kết nhóm driver nào đó với chuỗi nhiệm vụ cụ thể để điều khiển các driver nào sẽ được triển khai bằng cách sử dụng chuỗi nhiệm vụ đó.

Trong MDT 2010, bạn không thể tạo các nhóm driver dài hơn cách sử dụng Workbench vì không thể tạo các thư mục tùy chỉnh thay vì, đó là cách thức cung cấp cho bạn sự linh hoạt. Mặc dù vậy bạn vẫn có thể định nghĩa các nhóm driver mới bằng DriverGroup và sử dụng nó như một biến bên trong chuỗi nhiệm vụ của mình để điều khiển driver nào sẽ được triển khai vào máy tính mục tiêu dựa trên model và nhà sản xuất máy tính.

Mẹo: Nếu bạn không chắc chắc về model hay nhà sản xuất máy tính của mình, hãy sử dụng kịch bản WMI có trong phần 17 của loạt bài này để xác định rõ thông tin đó.

Đây là cách ban có thể chèn driver trong quá trình triển khai dựa trên model và nhà sản xuất máy tính mục tiêu. Bắt đầu bằng cách tạo một kiến trúc thư mục tùy chỉnh bên dưới thư mục Out-Of-Box Drivers của deployment share như dưới đây:

Out-Of-Box Folders
                Operating System
                                Make
                                                Model
                                                Model…
                                Make…
                Operating System…

Cho ví dụ, cho cả một số phần sau của loạt bài này, chúng tôi giả định rằng một công ty cần triển khai các phiên bản Windows khác nhau vào các hệ thống máy trạm sau:

• Các hệ thống Dell Optiplex 580 cần cài đặt Windows 7 x64 hoặc Windows 7 x86
• Các hệ thống Dell Precision T3500 cần cài đặt Windows 7 x64
• Các hệ thống Hewlett-Packard Pro 3015 Microtower cần cài đặt Windows 7 x64, Windows 7 x86 hoặc Windows XP SP3.

Hình 1 thể hiện cho các bạn thấy cấu trúc thư mục cho triển khai Windows 7 x64 vào các hệ thống khác nhau này như thế nào:

Hình 1: Cấu trúc thư mục cho triển khai Windows 7 x64 theo model và nhà sản xuất

Bạn sẽ cần tạo các cấu trúc thư mục tương tự như vậy bên dưới các thư mục Windows 7 x86 và Windows XP Professional. Sau đó import các driver cần thiết cho mỗi hệ thống vào một thư mục thích hợp khi đã thu được các driver này từ website của mỗi nhà sản xuất. Kết quả thu được sẽ tương tự như những gì bạn thấy dưới đây (hình 2):

Hình 2: Driver out-of-box đã được import cho các hệ thống Dell Optiplex 580

Lúc này mở thuộc tính của chuỗi nhiệm vụ được sử dụng để triển khai Windows 7 x64 vào máy tính mục tiêu. Bên dưới nhóm nhiệm vụ Preinstall, chọn nhiệm vụ đã có tên Configure trước nhiệm vụ chèn driver (Inject Drivers). Sau đó kích Add, chọn General, và chọn Set Task Sequence Variable như thể hiện trong hình 3 bên dưới:

Hình 3: Tạo một nhiệm vụ để thiết lập chuỗi nhiệm vụ mới có thể thay đổi trước nhiệm vụ chèn driver

Khi nhiệm vụ mới Set Task Sequence Variable được tạo, hãy chỉ định DriverGroup001 là tên của biến và gán cho biến này giá trị Windows 7 x64\%make%\%model% như thể hiện trong hình 4 bên dưới:

Hình 4: Chuỗi nhiệm vụ mới DriverGroup001 có giá trị Windows 7 x64\%make%\%model%

Những gì xảy ra khi nhiệm vụ này chạy là các máy tính mục tiêu của Dell Inc và model Optiplex 580 sẽ được chèn các driver trong thư mục Windows 7 x64\Dell Inc.\Optiplex 580, các máy tính của Dell Inc và model Precision T3500 sẽ được chèn driver trong thư mục Windows 7 x64\Dell Inc.\Precision T3500, còn các máy tính của Hewlett-Packard và model HP Pro 3015 Microtower được chèn driver trong thư mục Windows 7 x64\Hewlett-Packard\HP Pro 3015 Microtower khi triển khai. Chính xác hơn, chỉ có các driver trong các thư mục này mà PnP xác định cần chèn sẽ được chèn. Tuy nhiên khi sử dụng phương pháp này, các hệ thống Dell Optiplex 580 không thể chèn vào driver Dell Precision T3500 hoặc Hewlett-Packard Pro 3015 Microtower. Mỗi nhà sản xuất và mỗi model sẽ chỉ nhận các driver được thiết kế cho nó.

Mặc dù vậy chúng ta vẫn chưa xong ở đây vì nhiệm vụ Inject Drivers kế tiếp đã chọn All Drivers mặc định, và MDT sẽ chèn vào các driver dựa trên sự bổ sung của nhóm driver có thể áp dụng và profile chọn lọc. Vì vậy nếu nhóm driver nói chỉ có các driver Dell Optiplex 580 được cài đặt nhưng profile chọn lọc nói tất cả driver sẽ được cài đặt thì kết quả sẽ tất cả driver được cài đặt. Cụ thể hơn, PnP sẽ cài đặt các driver từ kho chứa driver có sẵn, không chỉ các driver được gán cho các hệ thống Dell Optiplex 580, có nghĩa chúng nên quay về phương pháp “để Windows quyết định” trừ khi có thể tránh sử dụng profile All Drivers. Mặc dù vậy đây là phương pháp đơn giản, bạn chỉ cần chọn nhiệm vụ Inject Drivers trong nhóm nhiệm vụ Preinstall và thay đổi profile từ All Drivers thành Nothing như thể hiện trong hình 5 bên dưới:

Hình 5: Chọn profile Nothing

Lúc này nếu nhóm driver nói chỉ có driver Dell Optiplex mới được cài đặt và profile nói không có driver nào được cài đặt thì kết quả sẽ chỉ có driver Dell Optiplex được cài đặt, đó là những gì chúng ta muốn.

Chìa khóa làm cho phương pháp làm việc là các thư mục tùy chỉnh mà bạn tạo cho nhà sản xuất và model phải tương ứng với nhà sản xuất và model có trong thuộc tính lớp Win32_ComputerSystem WMI cho mỗi hệ thống. Trong ví dụ ở trên, thư mục có tên Dell Inc. tương ứng với thuộc tính nhà sản xuất cho hai hệ thống, tuy nhiên các máy tính Dell cũ có thể với tên Dell Computer Corporation hoặc Dell Computer Corp. hoặc một giá trị khác khi thuộc tính nhà sản xuất được truy vấn bằng WM,I và nếu đang triển khai vào các hệ thống đó, bạn chắc chắn sẽ phải tạo các thư mục bổ sung có các tên đó.

Cuối cùng, lý do phương pháp trở đơn giản cho việc duy trì trong thời gian dài là vì, cho ví dụ, khi một driver mới được phát hành cho các hệ thống Dell Optiplex 580, bạn import driver vào thư mục Optiplex 580, sau đó chỉ cần thực hiện một triển khai test (cho một máy tính Dell Optiplex 580) trong lab của mình để bảo đảm driver mới sẽ không gây ra vấn đề gì với kiểu hệ thống này. Ngược lại, trong phương pháp “để Windows quyết định”, mỗi lần nâng cấp một driver, bạn cần thực hiện các triển khai test cho tất cả các kiểu hệ thống khác nhau của mình.

(Theo Windowsnetworking)

Phần 25: Quản lý driver - Selection Profiles

Trong hai phần trước của loạt bài này, chúng tôi đã bắt đầu giới thiệu cho các bạn cách sử dụng MDT 2010 để quản lý driver cho triển khai Lite Touch. Chúng ta đã biết được lý do tại sao driver lại làm phức tạp đến quá trình triển khai và đã khảo sát cách thức “Để Windows quyết định” trong việc import tất cả các driver không có sẵn trong hệ điều hành vào thư mục Out-of-Box Drivers của deployment share và cho phép liệt kê PnP trên các máy tính mục tiêu để quyết định xem driver nào cần được download từ deployment share và cài đặt. Nếu bạn sẽ triển khai Windows vào một vài model và chủng loại máy tính khác nhau, phương pháp đơn giản này nhìn chung làm việc khá tốt. Mặc dù vậy, nếu bạn triển khai Windows cho rất nhiều máy tính (khác nhau về kiểu dáng và chủng loại), đặc biệt nếu triển khai nhiều phiên bản Windows (chẳng hạn như Windows 7 và Windows XP) từ cùng một deployment share thì đôi khi bạn sẽ bắt gặp một số vấn đề với phương pháp này vì sự xung đột về driver. Cho ví dụ, bạn có thể phát hiện thấy các máy tính không cài đặt vào driver sai, chẳng hạn như driver cho Windows XP Professional lại được cài đặt vào hệ thống mà bạn đang triển khai Windows 7 x86.

Khả năng xung đột driver là một lý do tại sao thiết lập một máy chủ MDT riêng cho môi trường lab của bạn trước khi sử dụng nó cho triển khai trên mạng sản xuất lại quan trọng đến vậy. Cụ thể, môi trường lab của bạn cần phải có một máy tính mục tiêu cho mỗi model và chủng loại máy tính hiện có trong mạng sản xuất. Bằng cách đó, bạn có thể thử nghiệm phương pháp “Để Windows quyết định” để quản lý driver trong lab và xem liệu có xảy ra hiện tượng xung đột driver giữa chúng. Nếu không thấy xuất hiện xung đột, bạn có thể sử dụng phương pháp đơn giản này cho việc quản lý driver trong triển khai sản xuất. Còn nếu tháy xung đột, triển khai sản xuất của bạn sẽ cần một phương pháp chi tiết hơn để quản lý driver, đó là phương pháp mà chúng tôi gọi là “Để bạn quyết định”. Phương pháp này sử dụng hai tính năng mới có trong MDT 2010, đó là custom folders và selection profiles. Chúng ta sẽ nghiên cứu về hai tính năng mới này để kiểm thử phương pháp “Để bạn quyết định” làm việc ra sao.

Sử dụng phương pháp “Để bạn quyết định”

Trong phương pháp quản lý driver cho triển khai này, bạn có thể kiểm soát driver nào được cài đặt cho các kịch bản triển khai khác nhau. Để thực hiện điều này, hãy bắt đầu bằng cách tạo một cấu trúc thư mục bên trong deployment share có chứa driver khác nhau nhưng cần thiết cho mỗi kịch bản. Cho ví dụ, hãy giả sử bạn đang lên kế hoạch triển khai ba phiên bản Windows sau vào các máy tính mục tiêu khác nhau:

• Windows 7 Enterprise edition x64 cho các hệ thống mới
• Windows 7 Enterprise edition x86 cho các hệ thống cũ
• Windows XP Professional (x86) cho một số người dùng cụ thể, đây là những người cần dùng hệ điều hành này.

Để tránh xung đột driver gây ra bởi driver 32-bit được cài đặt trên phần cứng 64-bit hoặc ngược lại, hoặc xung đột có thể gây ra bởi driver Windows XP được cài đặt trên Windows 7 và ngược lại, bắt đầu bằng cách kích phải vào thư mục Out-of-Box Drivers trong deployment share và chọn New Folder từ menu xuất hiện. Thao tác trên của bạn sẽ khởi chạy New Folder wizard, trong cửa sổ tạo thư mục mới này, bạn cần đánh vào tên cho thư mục mới mà mình cần tạo (hình 1):

Hình 1: Tạo một thư mục mới mang tên Windows 7 x64

Kết thúc wizard để tạo một thư mục con Windows 7 x64 bên dưới thư mục Out-of-Box Drivers (xem hình 2). Thư mục con này là nơi bạn sẽ lưu các driver cần thiết cho việc triển khai Windows 7 x64 và các máy tính mục tiêu.

Hình 2: Thư mục Windows 7 x64 để lưu driver cho triển khai Windows 7 x64

Khi đã thực hiện xong các bước tương tự cho các hệ điều hành khác mà bạn muốn triển khai, cấu trúc thư mục của bạn sẽ giống như những gì thể hiện trong hình 3 bên dưới:

Hình 3: Cấu trúc thư mục để triển khai driver vào các hệ điều hành khác nhau

Giờ đây bạn sử dụng Import Driver Wizard như đã được giới thiệu trong phần trước của loạt bài này để import driver cần thiết cho mỗi hệ điều hành. Kết quả có thể giống như những gì bạn thấy trong hình 4 bên dưới:

Hình 4: Driver cần cho triển khai Windows 7 x64 đã được import

Custom folders là một tính năng mới khá mạnh trong MDT 2010, bạn có thể sử dụng chúng để tạo các cấu trúc thư mục cho các ứng dụng, hệ điều hành, driver, gói phần mềm và các chuỗi nhiệm vụ. Bạn càng tạo cấu trúc thư mục phức tạp hơn thì bạn càng có nhiều kiểm soát về triển khai của mình – đó là điểm mạnh của custom folders. Tuy nhiên cấu trúc thư mục phức tạp lại chính là điểm yếu của nó, vì nó gây khó khăn và tốn kém thời gian cho việc quản lý. Custom folders cũng có thể chuyển động bằng cách kéo và thả vào bên trong deployment share. Mặc dù vậy cần lưu ý rằng việc di chuyển một custom folder không thực sự là di chuyển tất cả các file bên trong được lưu trong thư mục hệ thống file, nơi chứa nội dung của deployment share. Nói cách khác, custom folders đơn giản chỉ là một cách logic để tổ chức các ứng dụng, hệ điều hành, driver, gói phần mềm và các chuỗi nhiệm vụ.

Bạn cần tạo selection profile. Một selection profile sẽ cho phép bạn chọn một hoặc nhiều thư mục trong deployment share. Selection profiles được sử dụng để nhóm các mục với nhau, hành động nhóm này có thể được thực hiện bởi nhiều lý do. Cho ví dụ, bạn có thể sử dụng selection profiles để chèn vào một tập các driver thiết bị thích hợp cũng như các gói phần mềm vào image Windows PE của bạn hoặc vào hệ điều hành của máy tính mục tiêu. Cũng có thể sử dụng selection profiles cho các mục đích khác như tạo các deployment share được liên kết (một điểm mới trong MDT 2010) hoặc cho việc tạo một media triển khai cụ thể.

MDT 2010 cũng có một số selection profile mặc định có thể được sử dụng cho các kịch bản triển khai với mục đích chung. Hình 5 bên dưới thể hiện các selection profile mặc định – lưu ý rằng selection profile được lưu trong thư mục Selection Profiles bên dưới thư mục Advanced Configuration trong deployment share của bạn.

Hình 5: Các selection profile mặc định trong MDT 2010

Các selection profile mặc định ở đây là:

• All Drivers – Gồm có tất cả các thư mục bên dưới thư mục Out-of-Box Drivers trong deployment share.
• All Drivers and Packages – Gồm có tất cả các thư mục bên dưới thư mục Applications và Out-of-Box Drivers trong deployment share.
• All Packages – Gồm có tất cả các thư mục bên dưới thư mục Packages trong deployment share.
• Everything – Gồm có tất cả các ứng dụng, hệ điều hành, driver thiết bị và gói phần mềm và các chuỗi nhiệm vụ trong deployment share.
• Nothing – Không có các thư mục có trong deployment share của bạn.
• Sample – Đây là một selection profile mẫu có tất cả các gói phần mềm và các chuỗi nhiệm vụ trong deployment share.

Để tạo một selection profile chỉ chứa driver cho các hệ thống Windows 7 x64, hãy kích phải vào thư mục Selection Profiles và chọn New Selection Profile. Khi New Selection Profile Wizard xuất hiện, đánh vào tên cho selection profile mới như thể hiện trong hình 6 bên dưới:

Hình 6: Bước 1 cho việc tạo một selection profile chỉ có driver cho các hệ thống Windows 7 x64

Kích Next , sau đó chọn thư mục con Windows 7 x64 bên dưới thư mục Out-of-Box Drivers như thể hiện trong hình 7:

Hình 7: Bước 2 cho việc tạo một selection profile chỉ có driver cho các hệ thống Windows 7 x64

Kết thúc wizard tạo selection profile mới bạn. Khi lặp lại các bước ở trên để tạo các selection profile bổ sung cho Windows 7 x86 và Windows XP Professional, danh sách các selection profile có sẵn của bạn trông giống như những gì thể hiện trong hình 8:

Hình 8: Ba selection profile đã được tạo

Hãy làm cho ba selection profile mới có thể kiểm soát driver nào được triển khai với hệ điều hành nào. Để thực hiện điều đó, chúng ta cần tạo ba chuỗi nhiệm vụ mới, mỗi một chuỗi nhiệm vụ cho mỗi một selection profile của chúng ta. Nói cách khác, một chuỗi nhiệm vụ sẽ được sử dụng cho Windows 7 x64, một cho Windows 7 x86, và một cho triển khai Windows XP Professional. Hình 9 thể hiện ba chuỗi nhiệm vụ của chúng ta:

Hình 9: Tao chuỗi nhiệm vụ mới cho mỗi selection profile mới

Để kết hợp một chuỗi nhiệm vụ cụ thể với một selection profile cụ thể, kích phải vào một chuỗi nhiệm vụ và chọn Properties để mở trang thuộc tính của nó. Sau đó chọn tab Task Sequence. Do muốn sử dụng selection profile để kiểm soát driver nào được chèn vào các image khởi động Windows PE của mình và vào hệ điều hành sẽ được triển khai vào máy tính mục tiêu, chúng ta cần cấu hình nhiệm vụ Inject Drivers bên trong nhóm nhiệm vụ Preinstall trong chuỗi nhiệm vụ của mình. Để cấu hình nhiệm vụ này, chọn nó phía bên trái và sau đó kích Choose A Selection Profile để chọn selection profile nào mà mong muốn (hình 10):

Hình 10: Chọn một selection profile cho nhiệm vụ Inject Drivers bên trong chuỗi nhiệm vụ Preinstall

Lưu ý: Chuỗi nhiệm vụ gồm có nhiều nhóm nhiệm vụ khác nhau (chẳng hạn như Initialization, Validation, State Capture,..) và các nhiệm vụ bên trong các nhóm này (như Gather Local Only, Inject Drivers, Apply Patches,...). Các nhóm nhiệm vụ cũng có thể gồm có các nhóm nhiệm vụ khác. Bạn có thể tạo các nhóm nhiệm vụ mới và các nhiệm vụ để tùy chỉnh cách thực hiện triển khai của bạn như thế nào. Chúng tôi sẽ giới thiệu kỹ hơn về vấn đề này trong phần sau của loạt bài này.

Do thuộc tính của chuỗi nhiệm vụ mà chúng ta đã mở là một trong những chuỗi nhiệm vụ cài đặt Windows 7 x64, do đó chúng ta cần liên kết Windows 7 x64 Drivers selection profile với chuỗi nhiệm vụ này như thể hiện trong hình 11:

Hình 11: Liên kết Windows 7 x64 Drivers selection profile  với chuỗi nhiệm vụ Windows 7 x64 Enterprise

Lưu ý trong hình trên, khi chọn một selection profile để chèn thêm các driver, bạn có hai tùy chọn. Tùy chọn đầu tiên là chỉ cài đặt các driver tương xứng từ selection profile trên máy tính mục tiêu. Nói cách khác, bảng liệt kê PnP chạy trên máy tính mục tiêu để xác định driver nào có trong các thư mục được chỉ định bởi selection profile, và chỉ các driver thực sự cần thiết với phần cứng của máy tính mục tiêu đó mới được cài đặt. Đây là thiết lập mặc định và bạn nên để nó như vậy.

Tùy chọn thứ hai là cài đặt tất cả driver từ selection profile, thậm chí nếu một số driver không cần thiết với phần cứng của máy tính mục tiêu. Bạn chỉ nên sử dụng tùy chọn này nếu có nhiều driver không thể phân biệt đúng cách bằng cách kiểm kê PnP trên máy tính mục tiêu. Driver cho hệ thống Bluetooth đôi khi cũng rơi vào trường hợp này, bằng cách chọn tùy chọn thứ hai, bạn có thể bảo đảm rằng các driver Bluetooth cần thiết cho phần cứng máy tính mục tiêu sẽ được cài đặt. Các ví dụ khác về phần cứng và driver nơi tùy chọn này cần thiết có thể là, để chuẩn bị trước driver NIC cần thiết cho các trạm docking của laptop được ngắt kết nối với các laptop của chúng và cho các máy in sẽ được kết nối sau khi triển khai kết thúc. Cần thận trọng khi chọn tùy chọn này – nếu cài đặt driver không cần thiết cho phần cứng của máy tính mục tiêu thì một số driver không cần thiết này có thể xung đột với driver cần cho phần cứng, vấn đề này đôi khi gây ra các kết quả không thể dự đoán trước.

Dù sao, lúc này tất cả những gì bạn cần thực hiện là sử dụng Lite Touch Windows PE CD (hoặc Lite Touch PE .iso với Windows Deployment Services) để khởi động máy tính mục tiêu, thực thiện qua các bước trong Windows Deployment Wizard, chọn chuỗi nhiệm vụ cho hệ điều hành bạn cần triển khai trên máy tính đó, MDT sẽ bảo đảm đúng driver cho hệ điều hành đó được cài đặt trên máy. Bạn có thể tự động hóa quá trình này ở một số phạm vi nào đó (xem phần trước trong loạt bài này để có thêm thông tin về cách thực hiện bằng việc chỉnh sửa file CustomSettings.ini hay cơ sở dữ liệu MDT).

  (Theo Quan Tri Mang)

Phần 24: Các vấn đề và phương pháp trong quản lý Driver

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 cách sử dụng MDT 2010 để chèn driver của thiết bị lưu trữ vào image khởi động Lite Touch Windows PE nhằm triển khai Windows cho hệ thống mà ở đó không có driver của thiết bị này. Trong phần đó chúng tôi cũng đã giới thiệu các bước import driver vào thư mục Out-Of-Box Drivers của deployment share. Tuy nhiên những gì bạn cần phải thực hiện khi chèn nhiều driver, khi có hàng trăm hoặc thậm chí hàng nghìn driver vào MDT cho các hệ điều hành khác nhau cần triển khai, bên cạnh đó là các kiến trúc hệ thống khác nhau (x86 hoặc x64), các model và hãng sản xuất khác nhau? Trong phần này chúng tôi sẽ giới thiệu cho các bạn một số tính năng mới trong MDT 2010 có thể quản lý các kịch bản driver phức tạp như vậy.

Tại sao driver lại làm phức tạp cho triển khai

Quả thực kịch bản triển khai đơn giản nhất cũng thường có hơn một hệ điều hành. Kịch bản triển khai thế giới thực thường liên quan đến việc triển khai tất cả các thành phần dưới đây vào máy tính mục tiêu:

• Hệ điều hành
• Driver thiết bị
• Ứng dụng
• Gói ngôn ngữ
• Các bản vá cho hệ điều hành và ứng dụng
• Các tùy chỉnh cho hệ điều hành và ứng dụng

Việc triển khai driver là một trong những nhiệm vụ khó khăn trong kịch bản triển khai thế giới thực. Một lý do cho điều đó là vì các tổ chức thường mua một số lượng máy tính lớn nhưng không thống nhất. Kết quả gây ra hiện tượng tồn tại nhiều chủng loại cũng như nhiều model hệ thống khác nhau từ các nhà sản xuất khác nhau và thậm chí có thể có nhiều hệ thống đặc biệt đi kèm. Điều đó làm cho cần phải có nhiều kiểu driver khác nhau để hỗ trợ cho tất cả các hệ thống trong tổ chức bạn.

Một lý do khác bổ sung thêm sự phức tạp cho các triển khai là vì các driver không chỉ cần thiết cho các hệ điều hành đã cài đặt để giúp hệ thống làm việc đúng cách mà chúng còn cần thiết cho việc khởi động hệ thống nhằm bắt đầu quá trình cài đặt. Như những gì các bạn đã thấy trong phần trước của loạt bài này, đôi khi một số driver (đặc biệt là các driver cho các thiết bị lưu trữ, thỉnh thoảng cũng có driver card giao diện mạng) cần được bổ sung thêm vào media khởi động Lite Touch Windows PE, bằng không bạn sẽ không thể khởi động máy tính mục tiêu để bắt đầu việc triển khai Windows cho các máy. May thay với các máy tính desktop, image khởi động Lite Touch Windows PE được tạo bởi MDT thường có khả năng khởi động máy tính, kết nối đến deployment share qua mạng và tiếp tục với cài đặt. Mặc dù vậy với các máy chủ có card RAID hoặc các sản phẩm khác, bạn cần phải bổ sung thêm driver cho Windows PE để thực hiện việc cài đặt này.

Một lý do khác khiến các driver làm cho quá trình triển khai trở nên khó khăn là vì sự không tương thích. Cho ví dụ, có một số tình huống mà ở đó việc cài đặt driver sai trên một hệ thống có thể làm cho hệ thống bị lỗi màn hình xanh “bluescreen”. Đây là một vấn đề rất có thể xảy ra đối với các driver của thiết bị lưu trữ. Hoặc đôi khi việc cài đặt hai driver giống nhau (một gần đây và một cũ) cho cùng một phần cứng cũng có thể làm cho driver sai được cài đặt vì sự thiết kế không chặt chẽ (chẳng hạn như INF dị hình). Hoặc đôi khi một hãng nào đó phát hành một driver mới cho một phiên bản phần cứng mới được nâng cấp và nói rằng driver mới sẽ hỗ trợ phiên bản phần cứng cũ, tuy nhiên khi thử nghiệm, bạn lại phát hiện thấy phần cứng cũ không làm việc tốt với driver mới.

Cuối cùng, khi triển khai phiên bản mới nhất của Windows, chẳng hạn như Windows 7, cả phần cứng mới và phần cứng cũ vẫn có thể gặp một số vấn đề về driver. Windows 7 quả thực có đến hàng tấn driver bên trong nhưng nó có không có các driver phù hợp cho phần cứng đã được phát hành sau bản RTM. Bên cạnh đó Windows 7 cũng có thể không có các driver thích hợp cho phần cứng từ thời Windows XP hoặc sớm hơn trước đó. Quả thực rất khó khăn trong việc tìm kiếm được đúng driver cho phần cứng trên website (giả định rằng hãng đó vẫn cung cấp các driver cho các phần cứng cũ). Khi download được driver, có thể bạn cần phải thực hiện nhiều bước để bung các file driver để import chúng vào deployment share của mình. Đó là vì Import Driver Wizard mà bạn thấy trong phần trước của loạt bài này chỉ có thể import các driver có các file INF có sẵn. Tuy nhiên, một số hãng thích phát hành phần mềm quản lý thiết bị bổ sung kèm theo driver của họ, kết quả là các driver đó đôi khi cần phải được cài đặt ở cuối quá trình triển khai bằng cách chạy thường trình Setup của hãng, đây là thành phần yêu cầu một số thao tác bổ sung cho chuỗi nhiệm vụ của bạn.

Các phương pháp khác cho việc quản lý driver trong triển khai

Có một câu hỏi là có nên thử và kiểm soát driver nào được triển khai cho các máy tính mục tiêu nào trong suốt quá trình triển khai, hay cho phép Windows sử dụng chế độ Plug and Play để quyết định driver nào sẽ được cài đặt trên các máy tính mục tiêu cụ thể. Nói cách khác, có hai phương pháp cơ bản các bạn có thể thực hiện để quản lý driver trong suốt quá trình triển khai: “hãy để bạn quyết định” và “hãy để Windows quyết định”. Chúng ta sẽ đi vào xem xét phương pháp thứ hai trước vì nó là phương pháp đơn giản hơn trong thực thi. Tuy nhiên trước khi thực hiện, hãy ôn lại một chút lịch sử.

Phương pháp cũ trong triển khai driver

Hầu hết các tổ chức thực hiện các triển khai máy trạm của họ bằng cách xây dựng một image cài đặt chủ, sau đó triển khai image này đến các máy tính mục tiêu của họ. Chúng ta đã thấy trong phần 10 của loạt bài này về cách sử dụng MDT để tạo một image chủ bằng triển khai Windows (cùng với các ứng dụng, gói ngôn ngữ, các bản vá và các tùy chỉnh khác) vào máy tính tham chiếu, sau đó capture image đã được sysprep của máy tính đó và upload nó vào deployment share của bạn. Trong phần 11 của loạt bài này, chúng tôi đã giới thiệu một cách tạo image chủ khác bằng việc khởi chạy máy tính được cấu hình trước và sử dụng chuỗi nhiệm vụ Sysprep và Capture mới để capture image chủ từ máy tính đó. Dù chọn cách nào thì đầu tiên bạn vẫn phải xây dựng imame chủ của mình (hoặc hai nếu cần triển khai cả Windows x64 và x86) bằng máy chủ MDT trong môi trường lab, sau đó triển khai các image chủ đến các máy tính mục tiêu bằng máy chủ MDT khác trên mạng sản xuất.

Giờ đây khi bạn xây dựng một máy tính chủ bằng máy chủ MDT thử nghiệm, nói chung bạn sẽ không muốn chèn bất cứ driver nào bên ngoài vào image chủ của mình. Nhiều năm cách đây, các quản trị viên xây dựng image chủ thường cho tất cả các driver của tất cả các kiểu máy tính mục tiêu khác nhau vào image chủ. Kết quả của việc cho tất cả các driver ngoài vào image chủ của họ thật khó hiểu – các imge lớn và khó duy trì, và các xung đột driver thường xuyên xảy ra – đôi khi gây ra cả lỗi màn hình xanh.

Khi BDD xuất hiện (kẻ tiền nhiệm trước MDT), BDD 2007 có bổ sung sự hỗ trợ bảng liệt kê Plug and Play thì nhu cầu cho việc đưa tất cả các driver bên ngoài vào một image chủ đã biến mất. Thay vào đó, bạn có thể cho phép Windows quyết định trong quá trình triển khai driver nào cần cho vào deployment share và cài đặt trên mỗi hệ thống mục tiêu. Sau đây chúng ta hãy đi tìm hiểu cách thực thi phương pháp này thế nào.

Sử dụng phương pháp “hãy để Windows tự quyết định” để quản lý driver

Trong phương pháp “hãy để Windows quyết định”, bạn chỉ cần import đơn giản tất cả các driver cho các máy tính mục tiêu vào deployment share của mình. Sau đó, khi sử dụng MDT để triển khai image chủ vào một hệ thống cụ thể bằng MDT, Windows sẽ sử dụng tính năng Plug and Play để xác định các driver ngoài nào cần được cài đặt trên mỗi hệ thống bằng cách so khớp các PnP ID của thành phần phần cứng với PnP ID được hỗ trợ bởi driver có sẵn – nói cách khác là bằng cách sử dụng bảng liệt kê Plug and Play.

Ưu điểm chính của phương pháp này là sự đơn giản. Vì đây là cách MDT thực hiện triển khai Lite Touch theo mặc định, tốn ít thời gian cố gắng ban đầu cần thiết cho việc lên kế hoạch quản lý driver cho triển khai – bạn chỉ cần kết xuất tất cả chúng vào deployment share và cho phép MDT và PnP thực hiện điều thần kỳ đó. Do không cần đến việc chuẩn bị trước và lên kế hoạch trước, nên bạn có thể nhanh chóng thực hiện phương pháp này.

Đây là thực hiện phương pháp trong thực tiễn. Giả sử rằng tổ chức của bạn sẽ chuyển từ Windows XP sang Windows 7 và có các hệ thống desktop dưới đây:

• Các hệ thống Dell Optiplex 580 cần cài đặt Windows 7 x64 hoặc Windows 7 x86
• Các hệ thống Dell Precision T3500 cần cài đặt Windows 7 x64
• Các hệ thống Hewlett-Packard Pro 3015 Microtower cần cài đặt Windows 7 x64, Windows 7 x86 hoặc Windows XP SP3.

Khi đã download tất cả driver cho các hệ thống này, copy chúng vào một thư mục, chẳng hạn như C:\Drivers trên máy chủ MDT sản xuất của bạn.

Hình 1: Driver của Dell và HP được import vào deployment share của bạn

Trong ví dụ này, các file driver của bạn đã tổ chức thành hai thư mục (Dell và HP) với các thư mục con là tên model. Bên dưới mỗi thư mục con với tên model là các thư mục con khác co hệ điều hành (chẳng hạn như Windows 7 x64 vs. x86) hoặc thiết bị (chẳng hạn như audio) hoặc số ID của gói phần mềm driver (ch for HP driver).

Để import tất cả các driver này vào deployment share, hãy mở Deployment Workbench, kích phải vào thư mục Out-Of-Box Drivers và chọn Import Drivers để khởi chạy Import Drivers Wizard. Sau đó kích Browse trên trang Specific Directory và chọn thư mục gốc C:\Drivers:

Hình 2: Chọn thư mục gốc, nơi lưu tất cả driver của bạn

Kích OK để trở về trang Specify Directory:

Hình 3: Import tất cả driver được tìm thấy trong C:\Drivers

Lưu ý rằng thao tác này sẽ import tất cả driver trong C:\Drivers và trong các thư mục con bên dưới thư mục nào. Kích qua các bước còn lại của wizard. Kết quả bạn sẽ thấy như dưới đây:

Hình 4: Tất cả các driver cần thiết cho triển khai desktop đã được import vào thư mục Out-Of-Box Drivers

Lưu ý rằng quá tình import có thể mất ít phút thực hiện vì có sẽ có nhiều MB driver cần import.

Giờ khi tất cả driver đã được import vào deployment share, bạn có thể sử dụng MDT để triển khai image chủ của mình vào các máy tính mục tiêu. Khi image chủ đang được triển khai, Windows sẽ sử dụng bảng liệt kê PnP để xác định xem driver bổ sung nào trong deployment share cần được cài đặt trên máy tính mục tiêu để bảo đảm các thành phần phần cứng của nó sẽ hoạt động như thiết kế.

Phương pháp “để Windows quyết định” này có tác dụng đơn giản hóa – tuy nhiên cũng có một điểm yếu của nó. Các xung đột driver có thể xuất hiện ở các kiểu phần cứng nào đó, đặc biệt nếu bạn triển khai đa hệ điều hành từ deployment share của mình. Tuy nhiên nếu bạn chỉ triển khai một hệ điều hành, cho ví dụ Windows 7 x64, và chỉ có một vài model máy tính khác nhau thì phương pháp này sẽ hoạt động khá tốt. Nếu bạn thực hiện test phương pháp này trong môi trường thí nghiệm MDT, tuy nhiên chắc chắn bạn sẽ phát hiện thấy một số hệ thống đã cài đặt driver sai (cho ví dụ driver của Windows XP Professional đã được cài đặt trên hệ thống mà bạn sẽ triển khai Windows 7 x86), khi đó cần phải sử dụng một phương pháp khác để quản lý driver trong triển khai. Đó là phương pháp chúng tôi sẽ giới thiệu trong phần tiếp theo, mời các bạn theo dõi!

  (Theo Quan Tri Mang)