CAG PartnerUpGame tự chủ.
Dành riêng cho KTV.

Bắt đầu bằng hiện trạng và phạm vi ảnh hưởng. Một máy lỗi, một dãy lỗi và cả phòng lỗi là ba nhánh chẩn đoán khác nhau.

1. Ghi nhận nền tảng và phiên bản bootrom, sơ đồ mạng, IP server, vị trí image/ổ game/writeback và nhóm cấu hình máy trạm.
2. Hỏi thay đổi gần nhất; chụp lỗi, ghi thời điểm và chọn một máy hoạt động tốt để đối chứng.
3. Sao lưu cấu hình và xác nhận bản image có thể khôi phục. Thống nhất cửa sổ bảo trì trước thao tác ảnh hưởng nhiều máy.

Xác nhận: Hồ sơ ban đầu phải đủ để người tiếp nhận khác tiếp tục xử lý mà không cần đoán. Đây là quy trình thực hành đề xuất, điều chỉnh theo hiện trạng.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Cần xác định đúng sản phẩm, phiên bản và module đang làm nhiệm vụ boot, cập nhật hay tính tiền. Tên gọi quen miệng không đủ để chọn lệnh sửa.

1. Ghi tên bộ cài, build và ảnh trang thông tin phiên bản; với tên “CCU”, cần đối chiếu chính xác phần mềm KTV đang sử dụng.
2. Dùng nguyên tắc DHCP/PXE, image, mạng và lưu trữ để khoanh vùng; đối chiếu tên menu, driver và thao tác commit theo tài liệu đúng hãng.
3. Trước khi phối hợp CAG UpGame với hệ thống hiện có, kiểm tra đường dẫn, quyền ghi và dịch vụ cập nhật trên một nhóm thử nghiệm.

Xác nhận: Không suy diễn khả năng tương thích chỉ vì hai bộ cài đều chạy trong môi trường bootrom.

Đối chiếu: CCBoot Cloud Wiki · iCafeCloud Wiki.

Tách phiên bảo trì khỏi phiên khai thác để tránh đưa dữ liệu tạm hoặc cấu hình riêng của một máy vào image dùng chung.

1. Sao lưu image và cấu hình; ghi phiên bản trước sửa. Chỉ cho máy bảo trì được chọn quyền ghi theo cơ chế của nền tảng.
2. Thực hiện một nhóm thay đổi có chủ đích. Với CCBoot, khởi động kiểm tra máy Super Client trước khi lưu để phát hiện lỗi driver hoặc BSOD.
3. Tắt máy bảo trì, lưu thay đổi theo tài liệu hãng, trả về chế độ khai thác và thử một máy khác ngoài máy bảo trì.

Xác nhận: Máy thường khởi động được sau khi đóng image, game chạy đúng và trạng thái cấp phép được đối chiếu lại.

Đối chiếu: CCBoot: Super Client.

Lập lịch bảo trì và thử trên bản image dự phòng, đặc biệt khi cập nhật tính năng hoặc driver tầng thấp.

1. Kiểm tra dung lượng, bản sao lưu và phương án boot lại image trước đó; ghi build Windows đang chạy.
2. Theo hướng dẫn đúng phiên bản bootrom để cập nhật trên máy thử. Hoàn tất các lượt khởi động mà bản cập nhật yêu cầu.
3. Kiểm tra PXE, NIC, GPU, anti-cheat và Billing trên nhóm cấu hình đại diện trước khi phát hành image.

Xác nhận: Sau khi lưu và khởi động lại ở chế độ thường, build ổn định và không lặp tải cùng một bản cập nhật.

Đối chiếu: CCBoot: cập nhật Windows trên image.

Lưu mã dừng và xác định lỗi xuất hiện trước hay sau khi Windows nạp driver. Không mặc định cứ BSOD là image hỏng.

1. So sánh BIOS/UEFI, phiên bản driver và cấu hình với máy đang chạy; ghi chính xác mã dừng cùng thời điểm.
2. Nếu lỗi xuất hiện ngay sau cập nhật, thử lại image trước đó trên máy kiểm tra. Dùng driver từ hãng phần cứng và cơ chế PNP của nền tảng.
3. Nếu gặp INACCESSIBLE_BOOT_DEVICE, chuyển hướng kiểm tra đường truy cập ổ khởi động, storage/NIC driver và cấu hình boot; không chạy hàng loạt lệnh sửa boot không phù hợp hệ diskless.

Xác nhận: Thử khởi động nguội và khởi động lại trên nhóm máy bị ảnh hưởng trước khi nhân rộng.

Đối chiếu: CCBoot: kiểm tra driver trước lưu image.

Bản sao lưu chỉ có giá trị khi đã biết cách khôi phục và xác định rõ phiên bản cần quay lại.

1. Lưu image, cấu hình boot, cấu hình menu và thông tin đường dẫn liên quan trước thay đổi. Ghi người thực hiện và thời điểm.
2. Giữ bản đang vận hành tốt đến khi nghiệm thu xong; tránh ghi đè bản duy nhất khi đang có máy hoạt động.
3. Thử quy trình khôi phục trên máy/nhóm thử nghiệm. Với game online, kiểm tra nhà phát hành còn cho phép dùng phiên bản cũ hay không.

Xác nhận: Phiên bản quay lui phải boot được và đáp ứng yêu cầu kết nối hiện tại; không chỉ kiểm tra tệp sao lưu có tồn tại.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Nếu chưa có địa chỉ IP hợp lệ thì chưa nên xử lý image Windows.

1. Kiểm tra link NIC, dây/cổng switch và chế độ boot mạng. Đổi chéo với một cổng đang hoạt động để xác định phạm vi.
2. Đối chiếu VLAN, dải DHCP, lease còn trống và MAC máy. Kiểm tra dịch vụ cấp IP và đường đi đến server.
3. Nếu dùng DHCP trên router, đối chiếu cách phối hợp DHCP/Proxy DHCP của bootrom; tránh nhiều DHCP cấp cấu hình mâu thuẫn trong cùng miền quảng bá.

Xác nhận: Máy nhận đúng subnet và thông tin boot, xuất hiện yêu cầu PXE tại server.

Đối chiếu: CCBoot: thiết lập DHCP · CCBoot: DHCP bên thứ ba.

IP hợp lệ chỉ xác nhận bước cấp địa chỉ; cần kiểm tra riêng bước tải bootloader.

1. Chụp nguyên văn thông báo và ghi IP boot server, tên boot file cùng chế độ UEFI/Legacy.
2. Đối chiếu dịch vụ TFTP/Proxy DHCP, rule firewall và đường đi mạng theo tài liệu bootrom; kiểm tra đúng giao diện mạng server.
3. Thử một máy cùng VLAN. Nếu chỉ lỗi qua router/VLAN, kiểm tra relay và chính sách mạng thay vì thay image hàng loạt.

Xác nhận: Bootloader tải thành công và tiến đến bước kết nối image. Chỉ mở đúng luồng cần thiết, không tắt toàn bộ firewall làm cấu hình lâu dài.

Đối chiếu: CCBoot: dịch vụ DHCP/TFTP.

Bootloader, cấu hình firmware và image phải được nền tảng hỗ trợ đồng bộ.

1. Ghi chế độ boot hiện tại và yêu cầu của hệ điều hành/game trước khi đổi firmware.
2. Chọn bootloader tương ứng UEFI hoặc Legacy theo đúng phiên bản CCBoot/bootrom. Các bản iPXE có thể yêu cầu cách nạp chứng thư khác nhau.
3. Với Secure Boot, theo đúng hướng dẫn của hãng cho model main và bootloader; không nạp chứng thư trôi nổi hoặc xóa khóa firmware tùy tiện.

Xác nhận: Máy boot ổn định, Secure Boot ở trạng thái đáp ứng yêu cầu và game kiểm tra bảo mật hoạt động.

Đối chiếu: CCBoot: chọn boot PXE.

Trùng IP là một khả năng. Cần phân biệt với lỗi link, DHCP hoặc thiết bị trung gian.

1. Đối chiếu tên máy, MAC, IP và lease DHCP; tìm IP tĩnh nằm trong dải cấp động hoặc bản ghi trùng.
2. So sánh cấu hình với một máy tốt trong cùng VLAN. Xem nhật ký mạng tại thời điểm mất kết nối.
3. Chỉnh đúng bản ghi hoặc phạm vi cấp phát trong cửa sổ bảo trì; thử từng máy, không đổi cả dải IP khi chưa xác định nguồn lỗi.

Xác nhận: Mỗi máy có thông tin nhận diện nhất quán sau khởi động lại; không còn lease hoặc cấu hình xung đột.

Đối chiếu: CCBoot: phạm vi DHCP.

Tốc độ danh định của NIC server không đại diện cho tốc độ xuyên suốt từ ổ đĩa đến máy trạm.

1. Kiểm tra tốc độ link thực tế, lỗi cổng/cáp, uplink switch và tình trạng NIC trên cả server lẫn máy trạm.
2. So sánh một máy với nhiều máy đồng thời; theo dõi tải đọc ổ image/game, ghi writeback và băng thông tại thời điểm chậm.
3. Thử một tuyến mạng tốt. Chỉ điều chỉnh teaming, jumbo frame hoặc offload khi đã xác nhận hỗ trợ ở toàn tuyến và có số liệu đối chứng.

Xác nhận: So sánh cùng bài tải trước/sau; xác định được điểm nghẽn thay vì chỉ thấy tốc độ kết nối 10G.

Đối chiếu: CCBoot: tốc độ khi nhiều máy cùng boot.

Đo theo từng chặng ở cả thời điểm bình thường và lúc cập nhật để tránh quy kết nhầm cho bootrom.

1. Ghi game/khu vực máy chủ, thời điểm, số máy và tiến trình tải đang chạy. Kiểm tra mất gói tới gateway và đích được phép đo.
2. Đối chiếu mức sử dụng WAN với lịch tải/đồng bộ. DNS có thể ảnh hưởng phân giải tên, không tự giải quyết mọi vấn đề độ trễ trong phiên chơi.
3. Điều chỉnh lịch hoặc giới hạn tải theo chức năng nền tảng/router; thử một thay đổi rồi đo lại.

Xác nhận: Độ trễ và mất gói được đối chiếu dưới cùng tải. Một đích không trả lời ICMP không tự chứng minh mạng bị lỗi.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Đây thường là bài toán tải đồng thời; cần quan sát cả mạng lẫn hệ thống lưu trữ.

1. Đo một máy, một nhóm và nhiều máy; ghi thời gian từ PXE đến desktop theo cùng điều kiện.
2. Quan sát tốc độ link và tải ổ image/writeback, CPU/RAM server trong lúc boot; đối chiếu lỗi phần cứng.
3. Thử khởi động theo nhóm để khoanh vùng khả năng chịu tải. Chỉ nâng phần cứng hoặc chỉnh cache khi số liệu cho thấy đúng điểm nghẽn.

Xác nhận: Thử lại với số máy đồng thời tương đương, không dùng kết quả của một máy để kết luận cả phòng.

Đối chiếu: CCBoot: nhiều máy boot chậm.

Tìm tiến trình ghi thực tế trước khi tăng cache hoặc xóa dữ liệu.

1. Trên máy thử, mở Resource Monitor → Disk, sắp xếp theo Write và đối chiếu PID với tiến trình.
2. Kiểm tra Windows Update, launcher, phần mềm đồng bộ và lịch quét. Đối chiếu thời điểm ghi tăng với hoạt động tương ứng.
3. Nếu một thay đổi cần lưu lâu dài, xử lý trên image bảo trì theo quy trình rồi thử lại ở chế độ thường. Không vô hiệu hóa cập nhật bảo mật vô thời hạn để che triệu chứng.

Xác nhận: Mức ghi về nền hợp lý sau boot và không lặp cùng tác vụ cập nhật ở mỗi phiên.

Đối chiếu: CCBoot: xác định tiến trình ghi writeback.

Ưu tiên giữ phiên đang chạy và xác định ổ vật lý, không xóa file writeback của máy đang hoạt động.

1. Ghi dung lượng trống, lỗi hệ thống và các máy đang sử dụng ổ; kiểm tra tình trạng ổ bằng công cụ nhà sản xuất.
2. Thống nhất thời điểm bảo trì, cho máy liên quan dừng đúng quy trình rồi dùng chức năng quản lý của nền tảng để dọn hoặc chuyển lưu trữ.
3. Nếu có dấu hiệu hỏng ổ, sao lưu cấu hình cần thiết và lập phương án thay thế/khôi phục, tránh tiếp tục ép tải để thử.

Xác nhận: Kiểm tra dung lượng, lỗi I/O và khả năng ghi sau khi máy trạm hoạt động lại; dữ liệu cần lưu đã được bảo vệ.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Cache cần phù hợp tải và chừa tài nguyên cho hệ điều hành cùng các dịch vụ. Không có một tỷ lệ đúng cho mọi phòng.

1. Ghi RAM vật lý, mức dùng khi cao điểm và các dịch vụ cùng chạy; theo dõi dấu hiệu thiếu bộ nhớ.
2. Đối chiếu phân bổ cache theo tài liệu phiên bản bootrom và dung lượng RAM của cả server/máy trạm.
3. Thay đổi từng tham số, đo cùng bài tải; quay lại cấu hình trước nếu phát sinh thiếu RAM, ghi đĩa tăng hoặc mất ổn định.

Xác nhận: Đánh giá bằng thời gian boot và độ ổn định dưới tải, không chỉ dung lượng cache đã cấp.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Chưa đủ căn cứ. Nhiều I/O nhỏ, độ trễ tăng hoặc tác vụ đồng thời đều có thể tạo hiện tượng này.

1. Ghi thời điểm, latency, queue và tiến trình đọc/ghi. Đối chiếu boot đồng thời, tải game, quét virus hoặc sao lưu.
2. Kiểm tra log I/O, nhiệt độ và sức khỏe ổ bằng công cụ hãng; so sánh khi giảm tải có kiểm soát.
3. Chỉ kết luận lỗi ổ khi có bằng chứng phù hợp; tránh benchmark phá dữ liệu hoặc đo tải nặng trên server đang khai thác.

Xác nhận: Sau xử lý, độ trễ và thời gian phản hồi ở tải thực giảm; không chỉ nhìn một con số MB/s.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Kiểm tra đường dẫn và cách launcher nhận diện dữ liệu trước khi tải lại toàn bộ game.

1. Đối chiếu ký tự ổ, thư mục game và vị trí launcher giữa server với máy trạm.
2. Trên iCafeCloud, kiểm tra Game Fixes cho game cài cục bộ; lưu cấu hình đúng đường dẫn và khởi động lại máy thử theo hướng dẫn hãng.
3. Với game từ IDC, kiểm tra gói đã có dữ liệu tích hợp cần thiết; không bật chồng các cơ chế sửa đường dẫn khi chưa xác nhận yêu cầu.

Xác nhận: Launcher nhận đúng game và chuyển sang Play/Launch sau lần khởi động mới.

Đối chiếu: iCafeCloud: Game Fixes · iCafeCloud: game từ IDC.

Phân biệt game IDC với game quản lý cục bộ, và cập nhật tự động với tải tự động.

1. Với IDC, kiểm tra Settings → Game Settings → Allow IDC Game Update đã bật và đã lưu.
2. Đối chiếu thuộc tính match_only và Auto Download/Auto Update của game theo tài liệu; các mục này không có cùng tác dụng.
3. Kiểm tra game có trong danh sách quản lý, trạng thái cập nhật và dung lượng đích; ghi lỗi cụ thể nếu tiến trình thất bại.

Xác nhận: Xác nhận game đã lên phiên bản mong muốn trên server rồi thử ở máy trạm; không chỉ kiểm tra công tắc đang bật.

Đối chiếu: iCafeCloud: điều kiện cập nhật IDC.

Mỗi bộ dữ liệu cần một đầu mối ghi được thống nhất. Hai updater có thể tranh tệp, khác manifest hoặc ghi đè phiên bản.

1. Lập danh sách dịch vụ có quyền ghi: updater, launcher, đồng bộ và tác vụ theo lịch.
2. Thống nhất nguồn cập nhật chính cho từng thư mục, lịch chạy và quyền truy cập. Nếu cần chuyển nguồn, sao lưu cấu hình/manifest cần thiết và dừng luồng ghi cũ theo kế hoạch.
3. Thử với một game và một nhóm máy trước khi mở rộng; kiểm tra phiên bản, đường dẫn và tiến trình nền sau khởi động.

Xác nhận: Không còn hai tiến trình cùng quản lý việc cập nhật một bộ dữ liệu. Đây là nguyên tắc vận hành đề xuất, không phải cam kết tương thích mọi updater.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Khoanh vùng phần cập nhật nằm ở ổ game hay nằm trong profile/ổ hệ điều hành không được lưu sau phiên.

1. Ghi phần dữ liệu thực sự bị tải lại: game, launcher, runtime hay cấu hình tài khoản.
2. Đối chiếu đường dẫn cài, thư mục dữ liệu launcher và cơ chế liên kết của nền tảng. Với iCafeCloud, kiểm tra Game Fixes đúng game.
3. Phần cần lưu trong image phải xử lý qua phiên bảo trì; phần thuộc game disk cần cập nhật tại nguồn được chỉ định.

Xác nhận: Khởi động lại máy thường và kiểm tra không lặp cùng gói tải; không lưu cookie/tài khoản riêng của khách vào image chung.

Đối chiếu: iCafeCloud: đường dẫn và Game Fixes.

Lấy đúng mã VAN và đọc yêu cầu hiện tại của Riot; các mã lỗi không có cùng nguyên nhân.

1. Ghi build Windows, mã VAN, trạng thái Secure Boot/TPM và thay đổi BIOS hoặc image gần nhất.
2. Đối chiếu yêu cầu bảo mật của Vanguard với firmware và bootloader được bootrom hỗ trợ. Xác nhận lại trong Windows sau khi chỉnh.
3. Cập nhật theo hướng dẫn chính thức trên máy thử. Không dùng công cụ bypass anti-cheat hoặc tắt cơ chế bảo vệ để coi như đã sửa lỗi.

Xác nhận: Khởi động lại ở chế độ khai thác, mở game và kiểm tra mã lỗi đã hết; lưu cấu hình đã nghiệm thu.

Đối chiếu: Riot: mã lỗi Vanguard · Riot: yêu cầu bảo mật Vanguard.

Phân biệt save của nhà phát hành, save trong profile máy và cơ chế Cloud Save của nền tảng đang dùng.

1. Kiểm tra đúng tài khoản, game được hỗ trợ, đường dẫn save và thời điểm đồng bộ cuối.
2. Thoát game đúng cách và chờ đồng bộ hoàn tất; giữ bản save mới nhất để đối chiếu, tránh ghi đè bằng bản cũ.
3. Thử một lượt lưu/chuyển máy với tài khoản kiểm tra; nếu dùng iCafeCloud, đối chiếu Game Saves, dung lượng và chính sách lưu của hội viên.

Xác nhận: Tệp/tiến trình đúng xuất hiện trên máy thứ hai; không mặc định mọi game đều hỗ trợ cùng cơ chế lưu.

Đối chiếu: iCafeCloud: Game Saves.

Chưa. Dịch vụ cập nhật dữ liệu và quyền sử dụng trò chơi là hai phạm vi cần đối chiếu riêng.

1. Xác định nguồn game, chủ thể có quyền sử dụng và điều kiện của nhà phát hành cho môi trường phòng máy.
2. Với Steam PC Café, đối chiếu danh mục và giấy phép thương mại trong chương trình khi áp dụng.
3. Lưu hồ sơ phù hợp; không sử dụng crack, tài khoản chia sẻ trái điều khoản hoặc công cụ vượt cơ chế cấp phép.

Xác nhận: KTV giải thích được phần dịch vụ CAG cung cấp và phần quyền sử dụng trò chơi cần do bên phù hợp trang bị.

Đối chiếu: Steam PC Café · Steamworks: giấy phép thương mại.

Lưu mã lỗi, edition, kênh cấp phép và thay đổi gần nhất trước khi thao tác lại. Trạng thái này có thể liên quan cấu hình, phần cứng hoặc điều kiện kích hoạt.

1. Đối chiếu key/giấy phép đã cấp cho đúng máy, không cấp trùng vượt phạm vi cho phép. Kiểm tra có mở image, thay main hoặc cài lại edition gần đây không.
2. Dùng trang Activation và thông tin chẩn đoán để đọc trạng thái. Che thông tin nhạy cảm trước khi gửi hỗ trợ.
3. Theo nhánh lỗi chính thức của Microsoft và phối hợp nhà cung cấp. Tránh kích hoạt lặp hàng loạt hoặc luân chuyển key giữa máy để thử.

Xác nhận: Kiểm tra lại sau khởi động và sau phiên đóng image; lưu kết quả theo mã máy, không chỉ chụp màn hình lúc vừa kích hoạt.

Đối chiếu: Microsoft: lỗi kích hoạt Windows.

Các lệnh dưới đây phục vụ đọc thông tin. Mở Command Prompt trên máy cần kiểm tra, đối chiếu thêm mục Activation trong Settings.

1. /dli hiển thị thông tin giấy phép cơ bản; /dlv hiển thị chi tiết hơn; /xpr hiển thị trạng thái hết hạn kích hoạt nếu có.
2. Ghi edition, trạng thái, kênh và thời điểm kiểm tra. Không công khai toàn bộ ảnh chẩn đoán có thông tin máy/tổ chức.

cscript //nologo %windir%\system32\slmgr.vbs /dli
cscript //nologo %windir%\system32\slmgr.vbs /dlv
cscript //nologo %windir%\system32\slmgr.vbs /xpr

Xác nhận: Kết quả đọc trạng thái hỗ trợ chẩn đoán kỹ thuật; không thay thế hồ sơ cấp phép.

Đối chiếu: Microsoft Learn: tùy chọn slmgr.vbs.

Không đưa thông tin cấp phép riêng của một thiết bị vào image rồi nhân ra cả phòng khi giấy phép không cho phép.

1. Lập bảng đối chiếu giấy phép với máy và xác định cơ chế triển khai phù hợp kênh cấp phép.
2. Trước khi lưu image, kiểm tra có thông tin key, tài khoản hay cấu hình riêng của máy bảo trì bị đưa vào bản dùng chung không.
3. Quy trình làm sạch và triển khai cần theo đúng kênh giấy phép/công cụ đang sử dụng; không áp dụng hàng loạt lệnh gỡ key hoặc rearm khi chưa có phương án hợp lệ.

Xác nhận: Các máy sử dụng đúng quyền được cấp sau mỗi lần khởi động và không xuất hiện việc gán trùng ngoài phạm vi cho phép.

Đối chiếu: Microsoft: phương thức kích hoạt Windows.

Khả năng chuyển phụ thuộc điều khoản của giấy phép đã mua; không suy luận từ việc key có kích hoạt được.

1. Đối chiếu loại giấy phép và hồ sơ mua; kiểm tra phiên bản Windows trước/sau thay đổi.
2. Nếu giấy phép cho phép và đã liên kết tài khoản phù hợp, dùng hướng dẫn kích hoạt lại sau thay phần cứng của Microsoft.
3. Giữ chứng từ và ghi lịch sử thay đổi thiết bị; phối hợp nhà cung cấp khi điều kiện chuyển hoặc trạng thái kích hoạt chưa rõ.

Xác nhận: Thiết bị mới có trạng thái hợp lệ theo giấy phép và thiết bị cũ được xử lý theo điều khoản áp dụng.

Đối chiếu: Microsoft: kích hoạt lại sau thay phần cứng.

Nên có hồ sơ đủ để đối chiếu sản phẩm, nguồn cung, phạm vi quyền sử dụng và thiết bị thực tế.

1. Danh mục phần mềm/edition, số lượng và loại giấy phép; hợp đồng hoặc thỏa thuận cấp quyền phù hợp.
2. Hóa đơn và thông tin bàn giao, mã đơn, người tiếp nhận, thời điểm; thông tin key lưu qua kênh hạn chế truy cập.
3. Bảng đối chiếu máy trạm/server với giấy phép và nhật ký cấp đổi hoặc thay phần cứng.

Xác nhận: Hóa đơn là chứng từ của giao dịch, không tự mở rộng quyền sử dụng vượt điều khoản của chủ sở hữu.

Đối chiếu: Nghị định 70/2025/NĐ-CP về hóa đơn · Luật 131/2025/QH15 sửa đổi Luật SHTT.

Thuế phải được xác định theo bản chất từng hạng mục, không theo tên gọi chung của gói dịch vụ.

1. Sản phẩm phần mềm và dịch vụ phần mềm đủ điều kiện thuộc đối tượng không chịu thuế GTGT theo quy định áp dụng.
2. Hạng mục khác đi kèm cần được phân loại riêng trên hồ sơ/hóa đơn; không đồng nhất “không chịu thuế” với thuế suất 0%.
3. Đối chiếu thông tin đơn vị mua và nội dung giao dịch với kế toán trước khi lập hóa đơn.

Xác nhận: Bảng giá là giá gói công bố; phân loại thuế trên hóa đơn cần đúng thực tế. Nội dung giải thích này không thay đổi số tiền hay công thức đang dùng của hệ thống.

Đối chiếu: Luật Thuế GTGT 48/2024/QH15, khoản 21 Điều 5 · Cổng Chính phủ: hướng dẫn về dịch vụ phần mềm, 13/07/2026.

Chữ ký số và đánh giá uy tín của SmartScreen là các cơ chế khác nhau. EV không còn mặc nhiên giúp bỏ qua SmartScreen.

1. Tải từ nguồn chính thức; kiểm tra Digital Signatures, tên nhà phát hành và tính hợp lệ của chữ ký.
2. Ghi tên tệp, phiên bản, mã băm nếu cần và nội dung cảnh báo; gửi nhà phát hành để đối chiếu.
3. Nếu chưa xác minh được nguồn/tính toàn vẹn, dừng triển khai tệp đó. Không hướng dẫn khách tắt Defender/SmartScreen đồng loạt.

Xác nhận: Chỉ tiếp tục theo kết quả xác minh và chính sách bảo mật của đơn vị, không dựa riêng vào nhãn “EV”.

Đối chiếu: Microsoft: SmartScreen và chứng thư EV.

Giữ đầu mối kỹ thuật mà khách tin tưởng và xác định rõ hạng mục cần triển khai.

1. Khảo sát cùng KTV phụ trách; thống nhất nhu cầu UpGame, bản quyền hoặc công cụ hỗ trợ, quyền truy cập và lịch làm việc.
2. Thử trên nhóm máy đại diện trước khi mở rộng. Mọi thay đổi Billing/hội viên cần được khách xác nhận và có bản sao lưu.
3. Bàn giao cấu hình, hồ sơ cấp phép và những việc còn theo dõi cho KTV tiếp quản; thống nhất đầu mối tuyến 2 khi cần.

Xác nhận: KTV hiện tại hiểu được cấu hình mới và tiếp tục chủ động vận hành; không để khách bị phụ thuộc vào một phiên hỗ trợ duy nhất.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

Gói thông tin tốt giúp giảm vòng hỏi lại và bảo vệ thời gian vận hành của khách.

1. Gửi mã phòng/máy, nền tảng và build, nhóm cấu hình, thời điểm lỗi, số máy bị ảnh hưởng cùng thay đổi gần nhất.
2. Mô tả các bước tái hiện và phép thử đã làm; kèm ảnh/log đã che Product Key, mật khẩu, số dư và thông tin hội viên.
3. Nêu cửa sổ bảo trì, người tiếp nhận và phương án quay lui đang có. Cấp quyền hỗ trợ đúng phạm vi và thu hồi khi kết thúc.

Xác nhận: Báo kết quả sau khởi động lại và ghi nhật ký xử lý; không dùng việc “đã kết nối từ xa” làm dấu mốc nghiệm thu.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.

CAG Billing Free là lựa chọn để tìm hiểu phần mềm tính tiền CAG theo điều kiện của bản phát hành hiện hành. V2 đang được chuẩn bị ra mắt.

1. Tham khảo tài liệu và bộ cài từ kênh chính thức; kiểm tra phiên bản trước khi triển khai.
2. Theo dõi thông báo V2 để xác nhận ngày phát hành, tính năng và quyền lợi, không coi tính năng dự kiến là cam kết của bản đang dùng.
3. Nếu muốn chuyển dữ liệu hội viên, khảo sát riêng và thử bản sao dữ liệu trước khi thống nhất thời điểm chuyển.

Xác nhận: Khách hiểu rõ mình đang dùng phiên bản nào, quyền lợi nào và hạng mục nào mới ở mức thông báo.

Đối chiếu: CAG: hướng dẫn Billing · Kênh thông báo CAG.

Quyền quản trị tài khoản không đồng nghĩa được tùy ý sử dụng dữ liệu cá nhân của khách hoặc hội viên.

1. Xác định mục đích, phạm vi và căn cứ xử lý; cung cấp thông tin cần thiết cho chủ thể dữ liệu theo trường hợp áp dụng.
2. Phân quyền đúng người, chỉ thu thập phần cần thiết, giới hạn chia sẻ và thời gian lưu phù hợp nghĩa vụ pháp lý/thỏa thuận.
3. Khi hỗ trợ từ xa hoặc gửi log, che thông tin nhạy cảm; phối hợp đơn vị vận hành để xử lý yêu cầu và sự cố dữ liệu.

Xác nhận: Đối chiếu Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP có hiệu lực từ 01/01/2026; không dùng câu “bảo mật tuyệt đối” thay cho biện pháp thực tế.

Đối chiếu: Luật Bảo vệ dữ liệu cá nhân · Nghị định 356/2025/NĐ-CP.

Nghiệm thu cần phản ánh phiên vận hành thực tế và phạm vi công việc đã thống nhất.

1. Kiểm tra boot nguội/khởi động lại ở từng nhóm cấu hình; mở game đại diện, kiểm tra mạng, âm thanh và thiết bị ngoại vi liên quan.
2. Đối chiếu cấp phép, menu, lưu game và Billing nếu thuộc phạm vi triển khai; thử dưới mức tải đã thống nhất.
3. Lưu phiên bản image/cấu hình, danh sách việc đã hoàn thành, tồn tại cần theo dõi, hồ sơ bàn giao và đầu mối tiếp nhận.

Xác nhận: KTV/khách xác nhận kết quả theo hạng mục; lưu phương án quay lui và nhật ký để xử lý lần sau.

Quy trình thực hành đề xuất của thư viện KTV. Đối chiếu tài liệu đúng nền tảng và hiện trạng trước khi áp dụng.