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!
DNS Requirements for the vCenter Server Appliance, lên DNS tạo các record A, PTR
Name vCenter Server 8
vcsa.viettechgroup.lab
IP: 172.16.23.3
Host Esxi or vCenter
IP: 172.16.1.1
If you want to deploy the appliance on an ESXi host, verify that the ESXi host is not in lockdown or maintenance mode and not part of a fully automated DRS cluster
Gồm 8 bước điền các thông tin như các bước chuẩn bị
B1: Introduction -> next
B2: End user license agreement-> Chọn chấp chập và next
Bước 3: Khai báo thông tin host esxi hoặc vcenter cần triển khai
Chọn Yes trust SSL
Bước 4: Khai báo VM tên và user root của VM VCSA
Bước 5: Để default tiny
Bước 6: Chọn Datastores cần Setup
Bước 7: Bước này quan trọng khai báo về port group VM network nào cần sử dụng để VM VCSA có thể liên hệ với ADDS, khi báo như hình tùy theo nhu cầu thực tế mạng của các bạn để gỏ vào.
Bước 8: chỉ là confirm các setting vừa rồi chọn finish
và quản lý vcenter https://ip:443 bằng vsphere client html5
Đây là quản lý máy ảo của VCSA 8 nhé
Tại đây có thể cập nhật các tùy chỉnh theo ý đồ quản trị
Lưu ý ae quản trị viên hay quên, nhớ cập nhật lại lại hệ thống password không là bị change password sau 90 ngày. 😊 Ở đây tùy ae nhé. Tôi thì có mình nên chơi never expires cho chắc ăn.
Mật khẩu vẫn để phức tạp đi
Cái quản trọng nữa là backup config sau khi cấu hình ngon lành để có trường hợp còn khôi phục lại nhé.
Người dùng có lẽ sẽ suy nghĩ lại với các câu trả lời của chatbot AI, sau khi họ biết được quy trình đánh giá độ chính xác của các phản hồi này được thực hiện như thế nào.
Google đã phát hành chatbot Bard dưới dạng giới hạn vào tháng 3 vừa qua, trong nỗ lực đáp trả ChatGPT của OpenAI.
Để đánh giá chất lượng các phản hồi của chatbot AI này, công ty đã thuê một lực lượng lớn các lao động từ bên thứ ba. Tuy nhiên, các đối tác thừa nhận rằng, họ thường không có đủ thời gian để đánh giá độ chính xác của những phản hồi truy vấn này.
Appen là một nhà thầu đang giúp cải thiện chatbot Google. Các nhân viên của công ty này không được thông báo rằng nhiệm vụ của họ liên quan đến Bard, nhưng các cuộc thảo luận nội bộ về nhiệm vụ mới bắt đầu từ ngày 7/2, khoảng thời gian gã khổng lồ tìm kiếm lần đầu tiên công bố chatbot AI của hãng
Những đối tác, được gọi là “người đánh giá”, thường xem xét thuật toán tìm kiếm của Google và mức độ liên quan của quảng cáo đặt trong kết quả tìm kiếm, cũng như gắn cờ các website độc hại để chúng không xuất hiện trên trang kết quả.
Nguồn tin của Insider cho hay, kể từ tháng 1, phần lớn công việc những người đánh giá đã chuyển sang xem xét các lời nhắc của AI. Họ nói rằng không có đủ thời gian để chấm điểm độ chính xác các phản hồi con bot đưa ra, do đó đôi khi họ chỉ có thể đưa ra “dự đoán tốt nhất”.
Bard đã nhận chỉ trích sau khi mọi người phát hiện ra chatbot đưa ra câu trả lời sai ngay trong sự kiện ra mắt. Google nói rằng, chatbot sẽ trở nên tốt hơn theo thời gian và không nên coi ứng dụng này là sự thay thế cho công cụ tìm kiếm.
Trước khi ra mắt, vào tháng 2, Google cũng yêu cầu các nhân viên dành từ 2 đến 4 giờ để kiểm tra con bot, đặt câu hỏi cho nó và gắn cờ những câu trả lời không đáp ứng tiêu chuẩn của công ty.
Các nhà thầu cho biết, họ có một khoảng thời gian nhất định để hoàn thành từng nhiệm vụ, từ ít nhất là 60 giây cho đến hơn vài phút. Tuy nhiên, những người đánh giá nói rằng rất khó để đánh giá phản hồi khi họ không hiểu về chủ đề chatbot đang nói đến, trong đó có các chủ đề kỹ thuật, chẳng hạn như blockchain.
Mỗi nhiệm vụ được giao thể hiện thời gian đều tính phí, do đó các nhân viên sẽ tìm cách hoàn thành nhiệm vụ ngay cả khi họ không thể đánh giá chính xác các phản hồi chatbot đưa ra.
Những nhân viên này nói rằng, họ muốn tìm hiểu đúng sự thật và cung cấp trải nghiệm chatbot chất lượng tốt nhất có thể, nhưng đơn giản là không có đủ thời gian nghiên cứu vấn đề trước khi đưa ra xếp loại.
“Bạn cần 3 giờ nghiên cứu để hoàn thành một nhiệm vụ 60 giây, đó là vấn đề chúng tôi đang gặp phải hiện nay”, một trong những người đánh giá chia sẻ.
Microsoft Outlook Zero-Day Vulnerability- Elevation of Privilege Vulnerability CVE-2023-23397
Tóm tắt:
Microsoft giải thích: CVE-2023-23397 là một lỗ hổng EoP nghiêm trọng trong Microsoft Outlook, được kích hoạt khi kẻ tấn công gửi thư có thuộc tính MAPI mở rộng với đường dẫn UNC đến chia sẻ SMB (TCP 445) trên máy chủ do tác nhân đe dọa kiểm soát. Không cần tương tác người dùng,”
Cơ chế
Kẻ tấn công đã khai thác thành công lỗ hổng này có thể truy cập hàm băm Net-NTLMv2 của người dùng, có thể được sử dụng làm cơ sở cho một cuộc tấn công Chuyển tiếp NTLM chống lại một dịch vụ khác để xác thực là người dùng.
Preview Pane
Hacker tận dụng tính Preview Pane của email Outlook Email được chế tạo đặc biệt sẽ tự động kích hoạt khi nó được ứng dụng khách Outlook truy xuất và xử lý, cung cấp một vectơ tấn công lén lút để tin tặc khai thác. “Kẻ tấn công có thể khai thác lỗ hổng này bằng cách gửi một email được chế tạo đặc biệt, email này sẽ tự động kích hoạt khi nó được ứng dụng khách Outlook truy xuất và xử lý. Điều này có thể dẫn đến việc khai thác TRƯỚC KHI email được xem trong Preview Pane,”
Các phiên bản ảnh hưởng
Tất cả các phiên bản được hỗ trợ của Microsoft Outlook (2010, 2013,2016,2019, 365Apps)cho Windows đều bị ảnh hưởng.
Các phiên bản khác của Microsoft Outlook như Android, iOS, Mac, cũng như Outlook trên web và các dịch vụ M365 khác không bị ảnh hưởng.
Biện pháp làm khắc phục:
Thêm người dùng vào Nhóm bảo mật người dùng được bảo vệ (Protected Users Security Group), ngăn việc sử dụng NTLM làm cơ chế xác thực. Việc thực hiện giảm thiểu này giúp khắc phục sự cố dễ dàng hơn so với các phương pháp vô hiệu hóa NTLM khác.
Chặn TCP 445/SMB gửi đi từ mạng của bạn bằng cách sử dụng tường lửa vành đai(DMZ), tường lửa cục bộ và thông qua cài đặt VPN. Điều này sẽ ngăn việc gửi thông báo xác thực NTLM tới chia sẻ tệp từ xa.
Máy trạm Client
Yêu cầu tất cả máy trạm của Người dùng cuối cần upgrade Microsoft Outlook cho các Phiên bản:
Microsoft Outlook 2013 (64-bit edition):https://www.microsoft.com/en-us/download/details.aspx?id=105070
Microsoft Outlook 2016 (64-bit edition):https://www.microsoft.com/en-us/download/details.aspx?id=105058
Microsoft Office LTSC 2019/2021/365 for 64-bit editions:=> Cick upgrade
