CÁCH CẬP NHẬT UPDATE HOST ESXI TỪ LIFECYCLE MANAGER VCENTER
NGỮ CẢNH
Có nhiều cách để ugprade host esxi 8, có thể upgrade từ host đơn, có thể cập cật online, hoặc offline từ lệnh. HÔm nay phương nguyễn giới thiệu tính năng cập nhật từ Lifecycle Manager của Vcenter (Tính năng đổi tên mà trước đó là Vmware Update Manager) ví dụ esxi 8.0 U1->8.0U2
CÁCH THỰC HIỆN
B1:Logon vào vCenter thao tác
B2: từ short cut-> Chọn vào Lifecycel Manager->Sync updates động tác này sẽ kết nối với server update lonline của vmware sẽ tải bản mới nhất về (version: esxi, cũng như driver mới nhất.). Lưu ý phải có kết nối internet nhé.
Ngoài ra chúng ta có thể import từ file iso để update nhé hoặc chúng ta có thể tạo 1 baseline cusmozine theo ý muốn chúng ta.
Bước 3: Sau khi chạy xong sync Update chúng lặp lại bước 2 mà chọn Sync HCL (Hardware Compatibility List)
Động tác này để cho hệ thống sẽ cập nhật nhận diện các driver tương thích phần cứng máy chủ esxi đang có trong vcenter
Bước 4: Chọn vào host cần Upgrade-> Updates=> Chọn vào Apply
Chọn Image-> Chọn customzie DELL
Chọn validate-> save
Nếu bị lỗi
The following VIBs on the host are missing from the image and will be removed from the host during remediation: vmware-fdm(8.0.1-22088981).
To prevent them from being removed, include appropriate components that are equivalent to these VIBs. If this is seen while switching from using Baselines to using Images, please refer to KB 90188.
Cần làm thủ tục remove ra trước khi ugprade
Connect to the ESXi with SSH
Confirm that fdm isn’t installed already : esxcli software vib list |grep fdm
esxcli software vib remove –vibname=vmware-fdm
Remove luôn
Chạy Remediating lại nhé
Chúng ta Update Thành công nhé.
Host đã lên version 8.0 u2
Tương tự cho host còn lại
Ngoài ra chúng ta có thể tuỳ chỉnh server download của Vmware nhé. Tuy nhiên nên đề mặc định.
Mô-đun Exchange Online PowerShell V3 dựa trên REST của chúng tôi là một công cụ mạnh mẽ cho phép bạn kết nối với Exchange Online và thực hiện nhiều tác vụ khác nhau bằng PowerShell. Đây là một cải tiến đáng kể so với mô-đun V2 trước đó về mặt bảo mật vì nó không phụ thuộc vào kết nối giao thức RPS.
Microsoft đã nghe một số phản hồi của khách hàng rằng mô-đun V3 tiêu thụ nhiều bộ nhớ hơn các mô-đun trước đó, điều này ảnh hưởng đến hiệu suất của tập lệnh và hệ thống của họ. Trong bài đăng blog này, chúng tôi sẽ chia sẻ một số mẹo về cách bạn có thể giảm mức tiêu thụ bộ nhớ của mô-đun V3 và tối ưu hóa tập lệnh của bạn để có hiệu quả tốt hơn.
Mẹo 1: Không tải gói trợ giúp
Một trong những nguồn tiêu thụ bộ nhớ chính trong mô-đun V3 là gói trợ giúp, chứa thông tin chi tiết và ví dụ cho từng lệnh ghép ngắn. Mặc dù điều này có thể hữu ích cho việc tìm hiểu và khắc phục sự cố nhưng nó không cần thiết khi chạy tập lệnh tự động. Do đó, chúng tôi khuyên bạn nên sử dụng tham số -SkipLoadingCmdletHelp đã được thêm vào để tối ưu hóa bộ nhớ trong bản phát hành mới nhất. Việc sử dụng tham số này sẽ bỏ qua việc tải gói trợ giúp vào quy trình PowerShell và do đó giảm đáng kể mức tiêu thụ bộ nhớ.
Mẹo 2: Chỉ tải các lệnh ghép ngắn cụ thể được tập lệnh yêu cầu
Bạn chỉ có thể tải các lệnh ghép ngắn mà bạn cần trong tập lệnh của mình. Theo mặc định, khi bạn chạy lệnh Connect-ExchangeOnline, mô-đun V3 sẽ tải hàng trăm lệnh ghép ngắn vào quy trình PowerShell. Điều này có thể sử dụng nhiều bộ nhớ và làm cho tập lệnh của bạn chậm hơn. Nếu tập lệnh của bạn chỉ sử dụng một vài lệnh ghép ngắn, bạn có thể sử dụng tham số -CommandName và chỉ chỉ định các lệnh ghép ngắn mà bạn muốn. Bằng cách này, chỉ các lệnh ghép ngắn được liệt kê mới được tải và mức sử dụng bộ nhớ có thể thấp hơn.
Ví dụ: nếu một tập lệnh cụ thể chỉ sử dụng các lệnh ghép ngắn Get-Mailbox và Get-User, bạn có thể sử dụng:
Mẹo 3: Tạo quy trình PowerShell mới cho mỗi kết nối Exchange Online mới
Mẹo cuối cùng là tạo quy trình PowerShell mới cho mỗi kết nối Exchange Online mới. PowerShell lưu trữ mọi thứ kể từ khi quá trình bắt đầu và bộ đệm sẽ chỉ bị xóa khi số lượng mục trong bộ đệm vượt quá một giới hạn nhất định. Giới hạn này thường không đạt được ngay cả sau nhiều lần chạy Connect/Disconnect-ExchangeOnline. Nếu tập lệnh của bạn ngắt kết nối và kết nối lại với Exchange Online nhiều lần trong cùng một quy trình PowerShell thì nhiều phiên bản của mô-đun V3 sẽ được lưu trữ trong bộ nhớ đệm, làm tăng mức tiêu thụ bộ nhớ. Do đó, chúng tôi khuyên bạn nên đóng quy trình PowerShell bất cứ khi nào bạn ngắt kết nối khỏi Exchange Online và tạo quy trình PowerShell mới nếu bạn muốn kết nối lại.
Ví dụ: thay vì sử dụng:
# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
# Do some tasks
# Disconnect from Exchange Online
Disconnect-ExchangeOnline
# Connect to Exchange Online again
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
# Do some more tasks
# Disconnect from Exchange Online again
Disconnect-ExchangeOnline
Bạn sử dụng lại:
# Start a new PowerShell process
Start-Process powershell
# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
# Do some tasks
# Disconnect from Exchange Online
Disconnect-ExchangeOnline
# Exit the PowerShell process
Exit
# Start another new PowerShell process
Start-Process powershell
# Connect to Exchange Online again
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
# Do some more tasks
# Disconnect from Exchange Online again
Disconnect-ExchangeOnline
# Exit the PowerShell process
Exit
Microsoft hy vọng rằng những mẹo này sẽ giúp bạn giảm mức tiêu thụ bộ nhớ của mô-đun Exchange Online PowerShell V3 và cải thiện hiệu suất tập lệnh của bạn. Nếu bạn có bất kỳ câu hỏi hoặc phản hồi nào, xin vui lòng để lại nhận xét bên dưới. Cảm ơn bạn đã đọc!
Làm cách nào để dọn dẹp thủ công Công tắc ảo phân tán (VDS) trên máy chủ ESXi?
Nếu máy chủ ESXi được kết nối với Bộ chuyển mạch ảo phân tán-Distributed Virtual Switch (DVS) và bạn không thể xóa nó khỏi kho vCenter đúng cách, thao tác này sẽ dọn sạch VDS như một phần của quá trình xóa, thì bạn sẽ chỉ còn lại cấu hình VDS cũ. Nôm na bị mất kết nối vCenter và dạng trên host còn tồn tại các VDS trên host không xoá bằng vCenter được nên phải dùng cách này.
Tất nhiên, quy trình làm việc lý tưởng là dọn dẹp phần này trong vCenter Server nhưng nếu bạn bị mất quyền truy cập hoặc Máy chủ vCenter đã bị xóa và bạn có thể tự hỏi làm cách nào để dọn dẹp phần này theo cách thủ công?
Bước 0 – Đảm bảo rằng không có máy ảo hoặc giao diện VMKernel nào đang sử dụng tài nguyên DVS và Nhóm cổng phân phối (DVPG). Tạo lại vSphere Standard Switch (VSS) và các nhóm cổng tương ứng, đồng thời cấu hình lại các máy ảo và giao diện VMKernel của bạn trước khi tiếp tục. Nếu bạn cần hỗ trợ, vui lòng tìm kiếm trực tuyến vì có nhiều tài nguyên nêu rõ các bước này và điều này sẽ không được đề cập trong bài viết này.
Lưu ý: Về lý thuyết, sau Bước 0, về mặt kỹ thuật, bạn có thể chuyển sang Bước 5 và chỉ cần xóa cơ sở dữ liệu VDS nhưng tôi muốn dọn sạch tài nguyên trước bước đó nhưng điều này cũng có tác dụng nếu bạn đang gặp khó khăn.
Bước 1 – Chạy lệnh sau để liệt kê VDS hiện tại và các cổng đường lên liên quan đã được định cấu hình. Trong ví dụ bên dưới, tôi có một VDS có tên foo với một đường lên vmnic1 đang sử dụng cổng 9 . Môi trường của bạn có thể được định cấu hình khác nhau, vì vậy vui lòng ghi lại những giá trị này vì bạn sẽ cần nó trong các bước tiếp theo.
esxcfg-vswitch -l
Bước 2 – Xóa đường lên khỏi VDS bằng cách chạy lệnh sau và chỉ định đường lên, cổng đường lên và tên VDS.
Copy từ Host vào VM Copy-VMFile “EX2019-01” -SourcePath “C:\Users\Administrator.VFC\WindowsAdminCenter1809.msi” -DestinationPath “C:\temp\WindowsAdminCenter1809.msi” -CreateFullPath -FileSource Host
Windows features
Use the following PowerShell command to install the OS component required for Microsoft UCMA 4.0 and the OS component required for Active Directory Preparation.
Như vậy là phương nguyễn đã hướng dẫn setup thành công cách cài đặt Exchange Server 2019 trên Windows Server Core, Còn việc cấu hình thì tương tự nhé. Chúng ta mốc vào web để quản trị
Máy chủ đang chạy SQL Server bị ngắt điện đột ngột sẽ bị lỗi databases vì dữ liệu đang ghi log chưa checkpoint cho nên sẽ bị in recovery mode hoặc recovery pending.
Kết quả chúng ta không thể truy cập như hình.
Kiểm tra tình trạng hay trạng thái databases
SELECT name, state_desc from sys.databases
Dùng lệnh bên dưới để kiểm tra
Một số trạng thái của dữ liệu như sau:
ONLINE
RESTORING
RECOVERING
RECOVERY_PENDING
SUSPECT
EMERGENCY
OFFLINE
COPYING
OFFLINE_SECONDARY
Trạng thái chúng ta đang bị là Recovering
Nguyên nhân gây lỗi
Một số nguyên nhân sư sau:
Máy chủ SQL bị tắt do lỗi. Nó có thể là phần cứng, sức mạnh hoặc thứ gì khác.
Đĩa có thể bị thiếu.
Tệp MDF hoặc LDF có thể bị thiếu
Đĩa đầy
Quá trình nâng cấp SQL không diễn ra tốt đẹp hoặc bị gián đoạn.
Sự thay đổi lớn đang được đưa ra nhưng có điều gì đó đã thất bại giữa chừng, chẳng hạn như những thay đổi đối với tính năng FileStream.
Tệp LDF (nhật ký) bị hỏng.
Tệp MDF (dữ liệu) bị hỏng. Tệp db của tệp MDF có thể bị hỏng vì nhiều lý do như sự cố đĩa hoặc SAN, lỗi phần cứng, vi rút, v.v.
Máy chủ đã khởi động lại và có gì đó đã thay đổi, chẳng hạn như thiếu đĩa hoặc thư mục hoặc thiếu quyền.
Cryptoware đã mã hóa các tệp SQL của bạn.
Cách xử lý
Trường hợp 1: Set Database state to ONLINE
Lỗi do disk full thì không thể set online cũng như start chúng ta phải mở rộng disk trước khi thực hiện.
ALTER DATABASE ‘AdventureWorks2019’ SET ONLINE;
DBCC CHECKDB(‘AdventureWorks2019’) WITH NO_INFOMSGS;
Trường hợp 2: Rebuilding lại log file và detach và attach file
Nôm na là setup mode emergency, sau đó detach, attach lại.
ALTER DATABASE [AdventureWorks2019] SET EMERGENCY;
ALTER DATABASE [AdventureWorks2019] set MULTI_USER;
EXEC sp_detach_db '[AdventureWorks2019]';
EXEC sp_attach_single_file_db @DBName = '[AdventureWorks2019]', @physname = N'MDF_FILE_FULL_PATCH';
Trường hợp 3: Initiate DBCC CHECKDB with REPAIR option
Admin bị và xử lý theo cách 3 sẽ ok chúng ta có thể rơi vào từng trường hợp để test nhé.
Trường hợp này có thể bị mất dữ liệu, tốt nhất có thể chuẩn bị bản backup, trước khi thao tác.
Hãy chắc chắn rằng bạn có một bản sao lưu. Đừng làm điều này trên db DUY NHẤT mà bạn có, vì sau khi sửa chữa hoàn tất, bạn có thể mất dữ liệu và bạn có thể không thích những gì đã bị mất!
DBCC CHECKDB với tùy chọn SỬA CHỮA là một giao dịch được ghi lại và có thể phục hồi. Điều đó có ý nghĩa gì với bạn? Điều đó có nghĩa là nếu bạn gói DBCC CHECKDB với REPAIR vào một giao dịch (thực thi BEGIN TRANSACTION trước khi chạy lệnh) và bạn không thích kết quả cuối cùng, thì bạn có thể hoàn nguyên giao dịch và quay lại nơi bạn đã bắt đầu. Bằng cách đó, bạn sẽ có thể Khôi phục các thao tác sửa chữa nếu cần thiết.
3.1. REPAIR_REBUILD
Có nhiều cấp độ sửa chữa khác nhau. Hãy thử bắt đầu với “REPAIR_REBUILD”, thực hiện sửa chữa mà không có khả năng mất dữ liệu:
Đặt cơ sở dữ liệu ở chế độ một người dùng
Chạy DBBC CHECKDB với “REPAIR_REBUILD”
Đặt cơ sở dữ liệu thành “online” và kích hoạt lại chế độ nhiều người dùng
Câu lệnh bên dưới lưu ý thay databases của các bạn vào nhé:
ALTER DATABASE DATABASENAME SET SINGLE_USER;
DBCC CHECKDB (DATABASENAME, REPAIR_REBUILD) WITH NO_INFOMSGS, ALL_ERRORMSGS;
ALTER DATABASE [DATABASENAME] SET ONLINE;
ALTER DATABASE [DATABASENAME] SET MULTI_USER;
Nếu sửa chữa thành công, cơ sở dữ liệu có thể được đặt lại về chế độ nhiều người dùng. Nếu không, mức độ sửa chữa “REPAIR_ALLOW_DATA_LOSS” là tùy chọn tiếp theo.
3.2. REPAIR_ALLOW_DATA_LOSS
Bước này có thể bị mất dữ liệu nhé 😊
Đặt cơ sở dữ liệu ở chế độ Khẩn cấp
Chạy DBBC CHECKDB với “REPAIR_ALLOW_DATA_LOSS”
Đặt cơ sở dữ liệu thành “ONLINE” và kích hoạt lại chế độ nhiều người dùng
Code Sql:
ALTER DATABASE [DATABASENAME] SET EMERGENCY;
ALTER DATABASE [DATABASENAME] SET SINGLE_USER;
DBCC CHECKDB (DATABASENAME,REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;
ALTER DATABASE [DATABASENAME] SET ONLINE;
ALTER DATABASE [DATABASENAME] SET MULTI_USER;
Check data
Kiểm tra lại trạng thái
Trường hợp 4: Restoring from Backup
Trường hợp này là sau cùng, các trường hợp trên không cứu được chúng ta buộc phải khôi phục từ backup.
Ngoài các công cụ sẵn có của MSSQL chúng ta có thể sử dụng áp thứ 3 trả tiền license để khôi phục hoặc sửa chữa:
When your memory ram becomes full, Windows moves data from your memory RAM to your hard drive, placing it in the page file (also known as the swap file).
SQL Server tends to go pear-shaped when it’s memory is paged to disk.
Optimal page file size settings for SQL Server
By default, the page file is auto managed by Windows.
You don’t want to trust the management of page file to Windows, as it won’t do what is optimal for SQL Server.
Page file sizing depends on the system crash dump setting requirements and the peak usage or expected peak usage of the System commit charge.
Both considerations are unique to each System, even for identical systems.
The old rules of thumb (Page file size = RAM * 1.5 or RAM * 2) makes no sense in modern systems, where the logic should be: the more RAM you have, the less you need paging file.
So, how should you size your Page File?
It depends on the specific workload and the type of server.
When sizing the page file, we need to consider our application’s memory needs and crash dump settings.
A good point of start is set 8-12 GB size for Kernel Memory dump on System with up to 256GB RAM.
You can learn more about it here.
How can I change the windows file size?
You can configure the page file by using System Properties:
Most important component in HA cluster is FDM (Fault Domain Manager) agent. It is responsible for some of following tasks:
Communicating host resource information,
VM states and HA properties to other hosts in the cluster.
Handles heartbeat mechanisms
VM placement
VM restarts
logging
As soon you enable the vSphere HA in a cluster, the Fault Domain Manager (FDM) agent service runs on each hosts in the cluster. There is one Master and other slave hosts in a vSphere cluster. Fault Domain Manager (FDM) agent is installed on all the slave or subordinate hosts that is used to communicate with the FDM of a master host.
FDM is installed into the ESXi hosts at /opt/vmware/fdm and stores its configuration files at /etc/opt/vmware/fdm.
FDM.log location and usage..
The log file named fdm.log is stored under /var/log/. If there is issue occurred in your environment, fdm.log is very helpful in order to troubleshoot it. For example if VMs are restarted without any known reason, this log file will show when and why this happened, for instance it could be due to host, network or storage failure.
How master host is elected?
An agent picks up the master host during election process (approximately 15 seconds) which is taken place between all the hosts. The host that can access the greatest no of datastores is elected as a master host. If more than one host sees the same no of datastores, the election process determines the master host by using the host Managed Object ID (MOID) assigned by vCenter Server
What happen if FDM fails:
when FDM runs it spawns a watchdog process, so in case of agent failure, the watchdog restart it.
Does vCenter talks to slave Hosts agents?
Yes when vCenter scanning for a HA master, when a host is reported as isolated or partitioned, or if the existing master informs vCenter that it cannot reach a slave agent.
How FDM communicates ?
FDM agent uses both the management network and storage devices for communication. All the HA agents (candidates for master) communicate with each other over the management network during election process by using User Datagram Protocol (UDP). All network connections are point-to-point. And once the mater host is elected, the master host and subordinate hosts communicate using secure TCP.
Thông tin bản cập nhật bảo mật(SU) Tháng 08/2023 Exchange Server
Ngày 08/08/2023 Microsoft đã phát hành Bản cập nhật bảo mật(SU) cho các lỗ hổng được tìm thấy: EX2016 CU23, EX2019 CU12,CU13
1/ CVE-2023-21709
Điểm nỗi bật bản này là giải quyết được lỗ hổng CVE-2023-21709 (khai thác TokenCacheModule trong IIS). Các bước cần thiết để giải quyết CVE-2023-21709 tốt nhất cài bản vá trước rồi hãy chạy script CVE-2023-21709.ps1
Cài đặt bản vá ngay lập tức để bảo vệ Exchange Server khỏi rủi ro có thể bị tổn thương:
Step 1. Cài bản vá bảo mật tháng 8/2023 cho Exchange Server 2016/2019-> link
Step 2. Reboot the Exchange Server
Step 3. Run the CVE-2023-21709.ps1 script này bản chất sẽ remove tokencachemolude trong IIS-> link
Các CVE bên dưới được xử lý bằng Bản cập nhật bảo mật:
CVE-2023-21709
CVE-2023-35368
CVE-2023-35388
CVE-2023-38181
CVE-2023-38182
CVE-2023-38185
2/ Hỗ trợ thay đổi thuật toán mã hóa mặc định trong Microsoft Purview Information Protection
Phần này chỉ áp dụng cho những khách hàng của MS sử dụng Exchange Server và Azure hoặc Dịch vụ quản lý quyền AD (RMS). Nếu bạn không biết đó là gì, những thay đổi về mã hóa Exchange Online CBC sẽ không áp dụng.
Bật hỗ trợ cho nội dung được mã hóa AES256-CBC trong Exchange Server đối với khách hàng nào sử dụng dịch vụ Azue hoặc AD (RMS) của MS.
Như đã thông báo trong phần Thay đổi thuật toán mã hóa trong bài đăng trên blog Microsoft Purview Information Protection, các SU Exchange Server tháng 8 năm 2023 chứa các bản cập nhật cho phép khách hàng sử dụng Exchange Server tại chỗ tiếp tục giải mã nội dung được bảo vệ bởi nhãn nhạy cảm Purview hoặc Dịch vụ quản lý quyền Active Directory. Vui lòng xem lại bài đăng trên blog đó để biết chi tiết và lịch trình, đồng thời đọc hỗ trợ AES256-CBC cho tài liệu Microsoft 365.
Nếu tổ chức của bạn bị ảnh hưởng bởi thay đổi này, sau khi cài đặt SU tháng 8 trên máy chủ Exchange của bạn, hãy xem bài viết về cách bật hỗ trợ mã hóa AES256-CBC. Xin lưu ý – bước này không cần thiết trừ khi máy chủ tại chỗ của bạn yêu cầu hỗ trợ cho AES256-CBC.
3/Giải quyết
Cài đặt DST không chính xác sau khi cập nhật hệ điều hành
4/Các sự cố đã biết với bản phát hành này
Những khách hàng bị ảnh hưởng bởi thay đổi mã hóa sắp tới của Microsoft 365 AES256-CBC cần thực hiện thao tác thủ công để bật thuật toán mã hóa mới sau khi SU được cài đặt vào tháng 8 năm 2023.
5/Note
Lưu ý rằng Exchange Server 2013 KHÔNG được hỗ trợ và bạn phải nâng cấp lên Exchange Server 2019 hoặc Exchange Online càng sớm càng tốt!
