แชนเนลของ MS Teams ไม่สามารถมีชื่ออุปกรณ์ MS-DOS ได้

• Microsoft Teams มี ขีดจำกัดการใช้งาน อย่างละเอียดครอบคลุมทั้งทีม แชนเนล แชต การประชุม และการแชร์ไฟล์ โดยชื่อแชนเนลไม่สามารถใช้ ชื่ออุปกรณ์ MS-DOS เช่น CON, PRN, AUX, NUL, COM1~COM9, LPT1~LPT9 ได้
• สมาชิกต่อทีมจำกัดที่ 25,000 คน, การเป็นสมาชิกทีมต่อผู้ใช้จำกัดที่ 1,000 ทีม, แชนเนลต่อทีมจำกัดที่ 1,000 แชนเนล และแชนเนลที่ถูกลบไปแล้วยังคงถูกนับรวมในขีดจำกัดระหว่าง ช่วงกู้คืน 30 วัน
• แชตมีเกณฑ์คือ แชตส่วนตัว 250 คน, การโทรด้วยเสียง/วิดีโอที่เริ่มจากแชต 20 คน, ไฟล์แนบ 10 ไฟล์, ไฟล์ 100MB และหากเกิน 20 คน ฟีเจอร์อย่าง การโทร·ตัวบ่งชี้การพิมพ์·การยืนยันการอ่าน จะถูกปิด
• การประชุมสามารถรองรับได้สูงสุด 300 คนหรือ 1,000 คนตามแผนบริการ และการประชุม Teams, เวบินาร์ และทาวน์ฮอลล์มี ขีดจำกัด 30 ชั่วโมง ส่วนห้องประชุมย่อยสร้างได้เฉพาะในการประชุมที่มีผู้เข้าร่วมน้อยกว่า 300 คน
• การแชร์ไฟล์พึ่งพา SharePoint และ OneDrive for Business ดังนั้นเทนแนนต์ที่ปิดใช้งาน SharePoint จะมีข้อจำกัด โดยไฟล์ของ Teams รองรับได้ 25TB ต่อไซต์หรือกลุ่ม และอัปโหลดไฟล์ได้สูงสุด 250GB ต่อไฟล์

---

ขีดจำกัดของทีมและแชนเนล

• จำนวนทีมที่ผู้ใช้สามารถสร้างได้เป็นไปตาม ขีดจำกัด 250 อ็อบเจกต์ ของ Microsoft Entra ID และผู้ดูแลระบบส่วนกลางได้รับการยกเว้นจากขีดจำกัดนี้
• ผู้ใช้สามารถเข้าร่วมเป็นสมาชิกทีมได้สูงสุด 1,000 ทีม โดยรวมทีมที่ถูกเก็บถาวรด้วย
• ขีดจำกัดหลักระดับทีมมีดังนี้
  • สมาชิก: 25,000 คน
  • เจ้าของ: 100 คน
  • ทีมทั้งองค์กร: 5 ทีมต่อเทนแนนต์
  • สมาชิกทีมทั้งองค์กร: 10,000 คน
  • จำนวนทีมในองค์กร Microsoft 365 หรือ Office 365: 500,000 ทีม
  • จำนวนทีมที่ผู้ดูแลระบบส่วนกลางสร้างได้: 500,000 ทีม
• แชนเนลต่อทีมมีได้สูงสุด 1,000 แชนเนล โดยเป็นการรวมกันของแชนเนลมาตรฐานและแชนเนลที่แชร์ รวมถึงแชนเนลส่วนตัวได้สูงสุด 30 แชนเนล
• แชนเนลที่ถูกลบสามารถ กู้คืนได้เป็นเวลา 30 วัน และในช่วงเวลานี้ยังคงถูกนับในขีดจำกัดแชนเนลต่อทีมและขีดจำกัดแชนเนลส่วนตัว
• โพสต์สนทนาในแชนเนลมีขนาดได้ประมาณ 100KB ต่อโพสต์ โดยรวมเนื้อหา ลิงก์รูปภาพ @mentions จำนวนคอนเน็กเตอร์ และ reaction
  • รูปภาพที่เข้ารหัสแบบ base64 จะไม่ถูกนับในขีดจำกัด 100KB

ข้อจำกัดของแชนเนลที่แชร์

• แชนเนลที่แชร์มีได้สูงสุด 1,000 แชนเนล ต่อทีม และแชนเนลที่ถูกลบจะถูกรวมอยู่ในช่วงกู้คืน 30 วัน
• แชนเนลที่แชร์หนึ่งแชนเนลสามารถแชร์กับทีมได้สูงสุด 50 ทีม โดยไม่นับทีมแม่
• สมาชิกแชนเนลที่แชร์มีสมาชิกโดยตรงได้สูงสุด 5,000 คน และทีมที่ถูกแชร์เข้ามาจะถูกนับเป็น 1 คนต่อทีมในการคำนวณขีดจำกัด
  • การอัปเดตแบบเรียลไทม์จะให้บริการได้ครั้งละ 25,000 คนเท่านั้น
  • รายชื่อแชนเนลจะแสดงเพียง 25,000 คน
• ผู้เข้าร่วมภายนอกรองรับเฉพาะ บัญชีที่ทำงานหรือโรงเรียน ของ Microsoft Entra
• แชนเนลที่แชร์รองรับแท็บ แต่ไม่รวม Stream, Planner, Forms
• บอต คอนเน็กเตอร์ และส่วนขยายข้อความไม่รองรับในแชนเนลที่แชร์
• ทีมทั้งองค์กรไม่สามารถเพิ่มเป็นสมาชิกของแชนเนลที่แชร์ได้
• เมื่อสร้างทีมใหม่จากทีมที่มีอยู่ แชนเนลที่แชร์ของทีมเดิมจะไม่ถูกคัดลอก
• การแจ้งเตือนของแชนเนลที่แชร์จะไม่ถูกรวมในอีเมลกิจกรรมที่พลาดไป
• แชนเนลที่แชร์ไม่รองรับในทีมชั้นเรียน

กฎห้ามใช้ชื่อแชนเนล

• ชื่อแชนเนลไม่สามารถใช้อักขระต่อไปนี้ได้
  • ~ # % & * { } + / \ : < > ? | ' " , ..
• ช่วงอักขระต่อไปนี้ก็ใช้ไม่ได้เช่นกัน
  • 0~1F
  • 80~9F
• คำต่อไปนี้ไม่สามารถใช้ในชื่อแชนเนลได้
  • forms
  • CON, CONIN$, CONOUT$
  • PRN, AUX, NUL
  • COM1~COM9
  • LPT1~LPT9
  • desktop.ini
  • _vti_
• ชื่อแชนเนลไม่สามารถขึ้นต้นด้วยขีดล่าง _ หรือจุด . และไม่สามารถลงท้ายด้วยจุด . ได้

การส่งข้อความและแชต

• การสนทนาที่อยู่ในรายการแชตของ Teams จะถูกเก็บไว้ใน กล่องจดหมาย Exchange Online ของผู้เข้าร่วม
• หากผู้ดูแลระบบต้องการค้นหาหรือเก็บรักษาการสนทนาแชต ผู้เข้าร่วมจำเป็นต้องมีกล่องจดหมาย Exchange Online บนคลาวด์
  • ในการปรับใช้ Exchange แบบไฮบริด ผู้ใช้กล่องจดหมายแบบ on-premises สามารถเข้าร่วมแชต Teams ได้
  • ในกรณีนี้ เนื้อหาการสนทนาดังกล่าวจะไม่สามารถค้นหาหรือเก็บรักษาได้
• ขีดจำกัดหลักของแชตส่วนตัวมีดังนี้
  • จำนวนคน: 250 คน
  • สมาชิกที่เพิ่มเข้าแชตกลุ่มได้ในครั้งเดียว: 200 คน
  • การโทรด้วยเสียง/วิดีโอที่เริ่มจากแชต: 20 คน
  • ไฟล์แนบ: 10 ไฟล์
  • ขนาดไฟล์: 100MB
  • ขนาดโพสต์แชต: ประมาณ 100KB
• หากจำนวนคนในแชตเกิน 20 คน ฟีเจอร์ต่อไปนี้จะถูกปิด
  • การตอบกลับอัตโนมัติของ Outlook และข้อความสถานะ Teams
  • ตัวบ่งชี้การพิมพ์
  • การโทรด้วยเสียง/วิดีโอ
  • การแชร์
  • การยืนยันการอ่าน
  • ปุ่ม Set Delivery Options
• เพื่อเพิ่มอัตราความสำเร็จในการส่งข้อความ แนะนำให้รักษาขนาดของข้อความเองไว้ไม่เกิน 80KB
• เทนแนนต์ที่ใช้การสมัครใช้งานแบบทดลองอาจได้รับข้อจำกัดการส่งข้อความที่เข้มงวดกว่าเพื่อป้องกันการใช้งานในทางที่ผิด และขีดจำกัดอาจถูกปรับได้โดยไม่แจ้งล่วงหน้า
• ผู้ดูแลระบบที่อนุญาตเฉพาะโดเมนที่เชื่อถือได้ในการเข้าถึงภายนอก สามารถเพิ่ม โดเมนที่เชื่อถือได้ 4,000 โดเมน ได้สูงสุด

อีเมลของแชนเนล

• อีเมลที่ส่งไปยังที่อยู่อีเมลของแชนเนลจะกลายเป็นส่วนหนึ่งของแชนเนล และใครก็สามารถตอบกลับเพื่อเริ่มการสนทนาได้
• ขีดจำกัดเมื่อส่งอีเมลไปยังแชนเนลมีดังนี้
  • ขนาดข้อความ: 24KB
  • ไฟล์แนบ: 20 ไฟล์
  • ขนาดต่อไฟล์แนบ: ต่ำกว่า 10MB
  • รูปภาพแบบอินไลน์: 50 รูป
• หากเกินขีดจำกัด พฤติกรรมจะแตกต่างกันไป
  • หากข้อความเกิน 24KB จะมีการสร้างข้อความตัวอย่าง และผู้ใช้ต้องดาวน์โหลดอีเมลต้นฉบับจากลิงก์ที่ให้มาเพื่อดู
  • หากจำนวนไฟล์แนบหรือรูปภาพเกินขีดจำกัด จะมีข้อความแสดงข้อผิดพลาด
• อีเมลของแชนเนลมีการจำกัดอัตรา
  • 6 อีเมลต่อ 10 วินาทีต่อผู้ใช้ต่อแชนเนล
  • 8 อีเมลต่อ 10 วินาทีต่อผู้ใช้ต่อเทนแนนต์
• อีเมลของแชนเนลไม่สามารถใช้ได้ใน Teams สำหรับองค์กร Office GCC/GCCH/DOD

การประชุมและการโทร

• แผน Microsoft 365 Business Basic, Business Standard, Business Premium, Microsoft Teams Essentials, Microsoft 365 A1 สามารถโฮสต์การประชุมออนไลน์ Teams และวิดีโอคอลได้สูงสุด 300 คน
• ในแผน Microsoft 365 F1/F3/E3/E5/A3/A5/G3/G5, Office 365 E1/E3/E5/A3/A5/G1/G3/G5, Microsoft Teams EEA ขีดจำกัดจะเพิ่มเป็นสูงสุด 1,000 คน
• ขีดจำกัดหลักเกี่ยวกับการประชุมมีดังนี้
  • การโทรด้วยเสียง/วิดีโอที่เริ่มจากแชต: 20 คน
  • ขนาดสูงสุดของไฟล์ PowerPoint: 2GB
  • ระยะเวลาที่ดาวน์โหลดไฟล์บันทึกการประชุมที่ไม่ได้อัปโหลดไปยัง Microsoft Stream ได้ในเครื่อง: 20 วัน
  • ความยาวสูงสุดของการบันทึกการประชุม: 4 ชั่วโมง หรือ 1.5GB
• เมื่อการบันทึกถึงความยาวหรือความจุสูงสุด การบันทึกจะสิ้นสุดและเริ่มใหม่โดยอัตโนมัติ
• ห้องประชุมย่อยสร้างได้เฉพาะในการประชุมที่มีผู้เข้าร่วม น้อยกว่า 300 คน
  • เมื่อสร้างห้องประชุมย่อย จำนวนผู้เข้าร่วมประชุมจะถูกจำกัดอัตโนมัติที่ 300 คน
• การประชุม Teams, เวบินาร์ และทาวน์ฮอลล์มีขีดจำกัดเวลา 30 ชั่วโมง

การหมดอายุของการประชุม

• การหมดอายุของการประชุมมีผลกับหมายเลขโทรเข้า PSTN, พิกัด CVI, นโยบายและการตั้งค่าการประชุมเริ่มต้น
• หากเข้าร่วมการประชุมหรืออัปเดตการประชุมก่อนหมดอายุ ระบบจะเพิ่ม 60 วัน ให้กับขีดจำกัดวันหมดอายุ ยกเว้นการประชุม Meet now
• ตามเกณฑ์ของ public preview ลิงก์และการประชุมใหม่จะหมดอายุตามเงื่อนไข และหลังหมดอายุแล้วจะไม่สามารถเข้าร่วมผ่านลิงก์ได้
  • การประชุมแบบครั้งเดียวที่กำหนดเวลาไว้: 60 วันหลังเวลาประชุมที่กำหนดไว้
  • Meet now ที่กำหนดเวลาจากปฏิทินหรือแชนเนล: 60 วันหลังสร้างลิงก์
  • Meet now ที่กำหนดเวลาจากแชตกลุ่ม: ไม่มีผล
  • การประชุมที่เกิดซ้ำและมีวันที่สิ้นสุด: ระยะเวลาที่นานกว่าระหว่าง 60 วันนับจากวันที่สิ้นสุด หรือ 60 วันนับจากครั้งสุดท้ายที่เกิดขึ้น
  • การประชุมที่เกิดซ้ำและไม่มีวันที่สิ้นสุด: 1 ปีหลังการเข้าถึงครั้งล่าสุด การเข้าร่วมครั้งล่าสุด หรือการอัปเดตการประชุมครั้งล่าสุด

ไลฟ์อีเวนต์

• Teams live events มีกำหนดสิ้นสุดใน กรกฎาคม 2026
  • อีเวนต์ที่กำหนดเวลาไว้แล้วจะได้รับการรองรับจนถึงวันที่ 28 กุมภาพันธ์ 2027
  • Microsoft แนะนำให้ใช้ Teams town hall สำหรับอีเวนต์ดิจิทัลและไฮบริดขนาดใหญ่
• ขีดจำกัดพื้นฐานของไลฟ์อีเวนต์มีดังนี้
  • ผู้เข้าร่วม: สูงสุด 10,000 คน
  • ความยาวอีเวนต์: 4 ชั่วโมง
  • ไลฟ์อีเวนต์ที่รันพร้อมกันได้ในองค์กร Microsoft 365 หรือ Office 365: 15 อีเวนต์
• ทันทีที่โปรดิวเซอร์เข้าร่วมไลฟ์อีเวนต์ อีเวนต์นั้นจะถือว่ากำลังรันอยู่
  • โปรดิวเซอร์ที่พยายามเข้าร่วมไลฟ์อีเวนต์ลำดับที่ 16 จะได้รับข้อผิดพลาด
• การเพิ่มขีดจำกัดชั่วคราวถูกขยายออกไปจนกว่าจะมีประกาศเพิ่มเติม
  • ผู้เข้าร่วมสูงสุด 20,000 คน
  • อีเวนต์พร้อมกันทั้งเทนแนนต์ 50 อีเวนต์
  • 16 ชั่วโมงต่อการบรอดแคสต์
• สามารถวางแผนไลฟ์อีเวนต์ที่มีผู้เข้าร่วมสูงสุด 100,000 คน ผ่าน Microsoft 365 assistance program ได้ โดยทีมจะประเมินแต่ละคำขอและตัดสินตัวเลือกที่เป็นไปได้

พื้นที่เก็บข้อมูลและการแชร์ไฟล์

• แต่ละทีมใน Teams มีไซต์ทีม SharePoint และแต่ละแชนเนลจะสร้างโฟลเดอร์ภายใน document library ของไซต์ทีมหลัก
• ไฟล์ที่แชร์ในการสนทนาจะถูกเพิ่มไปยัง document library โดยอัตโนมัติ และสิทธิ์กับตัวเลือกความปลอดภัยของไฟล์ที่ตั้งค่าใน SharePoint จะสะท้อนใน Teams
• แชนเนลส่วนตัวแต่ละแชนเนลมี ไซต์ SharePoint แยกต่างหาก
• หากไม่ได้เปิดใช้งาน SharePoint ในเทนแนนต์ ผู้ใช้ Teams จะไม่สามารถแชร์ไฟล์ในทีมได้เสมอไป
• การแชร์ไฟล์ในแชตส่วนตัวต้องใช้ OneDrive for Business ที่เชื่อมโยงกับไลเซนส์ SharePoint
• การแชร์ไฟล์ของ Teams ทำงานบนแบ็กเอนด์ SharePoint ดังนั้นส่วน Files ของ Teams จึงอยู่ภายใต้ข้อจำกัดของ SharePoint
• ขีดจำกัดพื้นที่เก็บข้อมูลของแผนที่แสดงมีดังนี้
  • 1TB ต่อองค์กร + 10GB ต่อไลเซนส์ที่ซื้อ
  • Office 365 Enterprise F1 คือ 1TB ต่อองค์กร
  • Teams Files สูงสุด 25TB ต่อไซต์หรือกลุ่ม
  • ขีดจำกัดการอัปโหลดไฟล์คือ 250GB ต่อไฟล์
• เนื่องจากแชนเนลถูกหนุนด้วยโฟลเดอร์ในไซต์ SharePoint สำหรับทีม แท็บไฟล์ของแชนเนลจึงใช้ขีดจำกัดพื้นที่เก็บข้อมูลร่วมกับทีมที่สังกัด

ทีมชั้นเรียนเพื่อการศึกษาและแท็ก

• Microsoft Teams for Education มีเทมเพลตสำหรับสถานการณ์ด้านการศึกษา เช่น การเรียนการสอนในห้องเรียน
• การใช้ทีมชั้นเรียนต้องมี ไลเซนส์ Office 365 Education
• ทีมชั้นเรียนเป็นไปตามขีดจำกัดสมาชิกทีมทั่วไป แต่บางแอปมีข้อจำกัดแยกต่างหาก
  • การใช้แอป Assignments: สมาชิก 1,000 คน
  • การใช้แอป OneNote Class Notebook: สมาชิก 300 คน
• ทีมชั้นเรียนสามารถรองรับสมาชิกได้มากกว่านี้ แต่หากวางแผนจะใช้ Assignments หรือ Class Notebook ควรรักษาให้อยู่ต่ำกว่าขีดจำกัดข้างต้น
• ขีดจำกัดของแท็กมีดังนี้
  • แท็กต่อทีม: 200 แท็ก
  • แท็กพื้นฐานที่แนะนำต่อทีม: 25 แท็ก
  • สมาชิกทีมที่กำหนดให้กับแท็กได้: 200 คน
  • แท็กที่กำหนดภายในทีมต่อผู้ใช้: 25 แท็ก

รายชื่อติดต่อและการรองรับเบราว์เซอร์

• Teams ใช้รายชื่อติดต่อใน Active Directory ขององค์กรและรายชื่อติดต่อที่เพิ่มไว้ในโฟลเดอร์หลักของ Outlook ของผู้ใช้
• ผู้ใช้ Teams สามารถสื่อสารกับใครก็ได้ใน Active Directory ขององค์กร และเพิ่มเข้าในรายชื่อติดต่อได้จาก Chat > Contacts หรือ Calls > Contacts
• บุคคลที่ไม่ได้อยู่ใน Active Directory ขององค์กรก็สามารถเพิ่มเป็นรายชื่อติดต่อได้จาก Calls > Contacts
• Teams presence ใน Outlook รองรับตั้งแต่แอปเดสก์ท็อป Outlook 2013 ขึ้นไป
• การรองรับเบราว์เซอร์แตกต่างกันไปตามฟีเจอร์
  • Internet Explorer 11 ไม่รองรับการโทร และรองรับการประชุมแบบจำกัดเฉพาะการประชุมที่มีพิกัด PSTN เท่านั้น
  • Microsoft Edge Chromium และ Google Chrome เวอร์ชันล่าสุดรองรับการโทรและการประชุมอย่างเต็มรูปแบบ
  • Firefox ไม่รองรับการโทรแต่รองรับการประชุม และการรองรับเต็มรูปแบบต้องใช้ปลั๊กอิน OpenH264
  • ขอบเขตการรองรับการโทร 1:1 วิดีโอ และการแชร์แตกต่างกันตามเวอร์ชัน Safari
• การประชุม Teams ในเบราว์เซอร์จำกัดไว้ที่สตรีมเดียว และจะแสดงได้เพียงอย่างใดอย่างหนึ่งระหว่างวิดีโอขาเข้าของผู้พูดปัจจุบันหรือการแชร์หน้าจอ
• หากต้องการมอบและรับสิทธิ์ควบคุมระหว่างการแชร์ ทั้งสองฝ่ายต้องใช้ไคลเอนต์เดสก์ท็อป Teams และไม่รองรับในเบราว์เซอร์

[xguru]

คงทำแบบนี้เพราะต้องรักษาความเข้ากันได้ย้อนหลังกับ Windows น่ะครับ

แต่ผมก็คิดว่านักพัฒนาสมัยนี้อาจไม่รู้จักพวก COM, LPT, PRN กันแล้วมั้ง ฮ่า ๆ

เดี๋ยวนี้ก็ยังเห็นคำถามประมาณว่า "ทำไมฮาร์ดดิสก์ถึงเริ่มจากไดรฟ์ C?" อยู่บ่อย ๆ..

[GN⁺]

ความคิดเห็นจาก Hacker News

• ราวปี 1998 ตอนเป็นวัยรุ่นผู้ คลั่ง Linux ผมเคยหิ้วเครื่อง Linux box ไปงาน LAN party และมันก็ใช้งานได้ดีจริง ๆ
  ตอนนั้น WINE แทบจะมีไว้เพื่อรองรับ Starcraft โดยเฉพาะ ส่วน Quake 2 ก็รันแบบเนทีฟได้ และแค่สองเกมนี้ก็ครอบคลุมเกมที่คนเล่นกันราว 95% แล้ว
  ครั้งหนึ่งผมคิดว่าคงตลกดีถ้ารันเชลล์สคริปต์ที่ไล่เปิด CON/CON บน Windows share ทุกเครื่องในเครือข่าย ปรากฏว่าแต่ละเครื่องขึ้น จอฟ้า ทันที และเพื่อน ๆ ก็ดูจะไม่ขำด้วยอย่างน่าประหลาด

  • นึกถึงสมัยนั้นเลย งาน LAN แต่ละครั้งต้องมีเพื่อนแบบนั้นสักคนเสมอ
    ถ้าเขาแก้ปัญหาเครือข่ายเก่งและพก สาย CAT-5 สำรองมาเสมอแบบเพื่อน BSD ของผม ก็น่าจะชดเชยได้มากพอ
  • อันนั้นทำผ่าน IPX หรือเปล่า? ผมจำไม่ได้ว่าเคยตั้งค่า IPX บน Linux
    ช่วงที่ผมใช้ Linux ถึงขั้นรัน Starcraft ผ่าน Wine ได้นั้น เหมือนว่ามันรองรับ IP อยู่แล้ว
  • ชอบเรื่องนี้มาก ไม่รู้มาก่อนว่า WINE มีมาตั้งนานขนาดนั้น และยังรันเกมอย่าง Starcraft ได้ด้วย
    ผมมีความทรงจำดี ๆ มากกับการเล่น Starcraft กับเพื่อน ๆ และเกมนั้นก็อายุยืนพอให้ผมติดมันตอนมัธยมต้น แล้วกลับมาติดอีกครั้งตอนมหาวิทยาลัย
  • สิ่งที่ดีที่สุดคือการแฮ็กแบบใคร ๆ ก็ทำได้ อย่างการยิง ping flood ใส่คนอื่นในงาน LAN party
    เป็นความทรงจำเก่า ๆ ที่ดี
  • มันเป็นยุคทองจริง ๆ ไม่รู้ว่าเป็นเพราะพวกเราแตกต่าง หรือโลกที่อยู่รอบตัวเราต่างออกไปกันแน่

• น่าจะเป็นเพราะในระบบไฟล์ของ Windows ไม่สามารถใช้ชื่อเหล่านั้นเป็นชื่อไฟล์หรือโฟลเดอร์ได้
  ช่องใน MS Teams จะสร้างโฟลเดอร์ที่สอดคล้องกันไว้ใน SharePoint สำหรับเก็บไฟล์แนบ

  • Microsoft ดูเหมือนเวลาเจอปัญหาก็คิดว่า “เข้าใจแล้ว งั้นสร้างมันบน SharePoint ละกัน”
  • ผมเคยทำงานที่ธนาคารแห่งหนึ่งซึ่งใช้ระบบเทรดดิ้งบน Windows ด้วยเหตุผลบางอย่าง ระบบจะสร้างโฟลเดอร์ที่เก็บรายละเอียดของสมุดบัญชีแต่ละเล่ม
    ปัญหาเกิดขึ้นเมื่อเทรดเดอร์คนหนึ่งตั้งชื่อสมุดบัญชีว่า LPT1
  • ตรงนี้ก็น่าจะมีช่องโหว่อื่นอยู่ด้วย แต่ดูเหมือนว่า % และ .. ก็ถูกใส่ไว้ใน blacklist ด้วย
  • มีการสร้าง กลุ่ม Active Directory ที่สอดคล้องกันด้วย
    เป็นวิธีที่ง่ายมากในการให้ผู้ใช้จัดการสิทธิ์เข้าถึงทรัพยากรได้โดยไม่ต้องเปิด support ticket ดังนั้นการใช้แบบนี้ก็ถือว่าโอเคทีเดียว
  • SharePoint ฝังเล็บลึกอยู่ใน Microsoft และจะยังคงเป็น ส้นเท้าอะคิลลีส ของพวกเขาตลอดไป

• ตอนแรกผมจะพูดว่า “นี่แทบจะเป็นการเผลอเผยให้เห็นว่าข้างในมีอะไรสยองอยู่ไม่ใช่หรือ การพูดแบบนี้ต่อสาธารณะควรน่าอาย เหมือนกับบอกว่าใช้ %s หรือ $PS1 ไม่ได้ แล้วทำไมถึงไม่ได้ล่ะ? เอา input ของผู้ใช้ไปทำอะไรกันแน่?”
  แต่ก็อาจเป็นปัญหาว่าชื่อช่องจะถูกนำไปจัดการที่อื่นอย่างไรด้วย ผู้คนอาจคัดลอกไปวางได้ทุกที่ และดูเหมือนจะไม่คาดหวังว่าผู้ใช้ Windows จะ escape สตริงของตัวเองด้วยตนเองตอนวางลงใน cmd, PowerShell หรือ WSL
  โค้ดของ Teams เองน่าจะจัดการได้ดี แต่ปัญหาอาจอยู่ที่เครื่องมือภายนอกสารพัดชนิดที่ไม่รู้ที่มาและทำแบบลวก ๆ ซึ่งอาจต้องจัดการชื่อช่อง
  คนอื่น ๆ ชี้ถึง โฟลเดอร์ SharePoint ที่เชื่อมกับช่องไว้แล้ว และการ escape, แปลงรูป หรือ encode เพื่อสร้างเวอร์ชันที่ปลอดภัยสำหรับไดเรกทอรีนั้นก็ทำได้ง่าย ดังนั้นโดยส่วนตัวผมยังไม่ค่อยอยากยกโทษให้ แต่ก็เป็นไปได้ว่าที่ไหนสักแห่งจำเป็นต้องให้ชื่อช่องกับชื่อไดเรกทอรีเหมือนกัน
  ถ้าใช้แค่ภายในแอป ก็แค่ encode/decode ชื่อช่องกับชื่อไดเรกทอรีด้วยวิธีเดียวกัน แล้วซ่อนจากผู้ใช้ให้หมดก็พอ แต่ถ้าไดเรกทอรีถูกใช้นอกแอปด้วย รูปแบบอย่าง URL encoding ก็จะถูกแสดงออกมาตรง ๆ และดูไม่สวย
  สุดท้ายแล้วชื่อไดเรกทอรีต้องปลอดภัยสำหรับทุกอย่างอื่นด้วย ดังนั้นชื่อช่องก็ต้องเป็นแบบเดียวกัน พวกเขาเลือกข้อจำกัดแบบนี้แทนที่จะมีชื่อไดเรกทอรีหน้าตาน่าเกลียดเป็นบางครั้ง และสุดท้ายมันใกล้เคียงกับ ปัญหาด้านรูปลักษณ์ มากกว่าปัญหาความปลอดภัยหรือความเสียหาย เพราะไม่อนุญาตตัวอักษรที่จำเป็นต้อง encode ตั้งแต่แรก ไดเรกทอรีทั้งหมดจึงดูเป็นธรรมชาติและสวยงามเสมอ

  • ถ้ามีโอกาสได้ดูฟีด DNS NXDOMAIN แบบดิบของ Passive DNS (PDNS) จะเห็นว่ามีของพัง ๆ เยอะมาก และบางส่วนก็ค่อนข้างชวนขนลุก
    เรื่องแบบนี้เกิดขึ้นเวลามีการแปลงระหว่างบริการตั้งชื่อกันไปมา โดยปกติบริการตั้งชื่อจะมีขอบเขตการใช้งาน และชื่อในบริบทหนึ่งอาจถูกตีความต่างออกไปในอีกบริบทหนึ่ง
    Bobby Tables เป็นตัวอย่างที่รู้จักกันดี แล้วชื่อไฟล์พิเศษอย่าง -rf ล่ะ? ครั้งหนึ่งพาธปกติของ Active Directory เคยแทบจะเชื่อถือชื่อโดเมน DNS โดยปริยายในที่อย่าง file share มันดูโอเคจนกว่าจะตระหนักว่าใน “ไดรฟ์” นั้นอาจมีไฟล์ executable อยู่
    พูดตามตรง ผมหาสตริง MS-DOS ในเอกสารนั้นไม่เจอ แก้ไข: เจอการอ้างอิงอย่าง CON, LPT1 แล้ว
  • ก็แค่ข้อจำกัดของชื่อโฟลเดอร์ SharePoint โผล่ขึ้นมาข้างบนเท่านั้น ไม่มีอะไรพิเศษ
  • “ไม่คาดหวังว่าผู้ใช้จะ escape สตริงของตัวเอง” นี่ ผู้ใช้ของระบบไหนเคยเริ่มทำได้ตามความคาดหวังแบบนั้นด้วยหรือ? ระบบยูโทเปียแบบนั้นมันอยู่ที่ไหนกัน?
  • AWS มีข้อจำกัดด้านตัวอักษรแทบทุกอย่างจริง ๆ
    แม้แต่ body ของข้อความ SQS ก็ยังจำกัดว่าใช้ whitespace character แบบไหนได้บ้าง
  • นี่เป็นข้อจำกัดของ SharePoint Teams สร้างอยู่บน SharePoint และนั่นก็ไม่ใช่ความลับหรือเรื่องน่าอายอะไร

• ทำไม แอปแชต/ประชุม ส่วนใหญ่ถึงลงเอยด้วยความห่วยแตกกันนะ? ยังจำช่วงที่ Teams เคยเป็นแอปที่พอใช้ได้อยู่ได้เลย เคยมีไคลเอนต์เดสก์ท็อปบน Linux ด้วย
  ยังจำตอนที่ Slack เร็วจริง ๆ ได้ และยังจำตอนที่ Skype out เสถียรกว่าสายโทรศัพท์มือถือของผมได้ด้วย
  ตอนนี้ Slack แค่เพิ่มองค์กรไม่กี่แห่งก็ช้าสุด ๆ แล้ว แต่ก็ยังเพิ่มได้มากกว่าหนึ่งอยู่ดี
  Teams เลิกทำไคลเอนต์เดสก์ท็อปบน Linux ไปแล้ว และถ้าจะใช้บน Linux ก็ต้องผ่าน Chrome แต่ถ้าใช้เป็นส่วนหนึ่งของ Office365/SharePoint ลิงก์ SharePoint “บางส่วน” ก็ต้องใช้ Firefox
  สุดท้ายก็ต้องมีเบราว์เซอร์ 2 ตัวตลอด ต้องใช้ Chrome สำหรับการแชร์หน้าจอและวิดีโอของ Teams และใช้ Firefox สำหรับลิงก์ SharePoint บางลิงก์

  • เชื่อยากก็จริง แต่แอปแชต/ประชุมคือประตูที่ง่ายที่สุดสู่การเป็น แอปทุกอย่าง แบบ WeChat
    ท้ายที่สุดแล้วแอปแชต/ประชุมก็คืออินเทอร์เน็ตย่อส่วน
    แอปแชตนั้นยอดเยี่ยม แต่แล้วถ้าส่งและแชร์คลิปเสียงได้ล่ะ คลิปวิดีโอ วิดีโอสด เงิน การประชุม คำเชิญปฏิทิน คำขอสั่งอาหารเดลิเวอรี เซสชันเกม X ได้ล่ะ
    X ไม่มีขีดจำกัด อินเทอร์เน็ตคือการแชร์ X และแอปแชตก็คือการแชร์ X เช่นกัน จึงไม่มีเส้นแบ่งจริง ๆ ว่ามันจะขยายใหญ่ได้แค่ไหน
  • แก่นสำคัญคือต้องทำให้ ห่วยแตกและเรียบง่าย ตั้งแต่ต้น IRC ทุกวันนี้ก็ทำงานได้แย่เหมือนเมื่อ 30 ปีก่อนเป๊ะ
  • ส่วนหนึ่งน่าจะเป็นเพราะแรงกดดันให้เพิ่มฟีเจอร์ไปเรื่อย ๆ
    แชตกับวิดีโอได้แล้ว แล้วถ้าใส่เบลอพื้นหลังด้วยล่ะ? ให้ตายสิ Zoom มีโพล งั้นเราก็ต้องมีโพลบ้าง ถ้าจะปล่อยฟีเจอร์รัว ๆ และ iterate เร็ว ๆ แบบนี้ ใช้ Electron ก็ได้มั้ง แนวทางก็ประมาณนี้
  • ตลาดให้รางวัลกับ ฟีเจอร์และการผสานรวม ไม่ใช่ประสิทธิภาพ ตราบใดที่แอปยังพอใช้ได้ นักพัฒนาก็พัฒนา… ไม่สิ ฟีเจอร์ ฟีเจอร์ ฟีเจอร์
  • ทีมสตาร์ทอัพที่คล่องตัวและผลิตภาพสูงสร้างแอปที่ทุกคนชอบ จากนั้นได้เงินลงทุนจำนวนมาก แล้วก็จ้างนักพัฒนาซอฟต์แวร์ที่ไม่จำเป็นเป็นพัน ๆ คน
    หลังจากนั้นก็ต้องหางานให้คนเหล่านั้นทำ

• อันนี้ดีมาก ผมชอบที่ของใหม่นี้ทำให้นึกถึง ยุคแรก ๆ ของ MS-DOS ช่วงต้นยุค 90 มาก ๆ ตอนที่รันบน 086 หรือ 286
  ต้องยอมรับความหมกมุ่นของ Microsoft กับความเข้ากันได้ย้อนหลังจริง ๆ ราวกับจินตนาการที่เป็นไปไม่ได้ว่าเนทีฟพอร์ตของ MS Teams จะถูกทำสำหรับ MS-DOS 3.1 ที่ดูเป็นไปได้กว่านิดหนึ่งคือจินตนาการว่าเซิร์ฟเวอร์ MS Teams กำลังรันอยู่บนเมนเฟรม MS-DOS 3.1 โบราณแบบ proprietary ที่พิลึก ๆ แต่ก็ยังฟังไม่ขึ้นอยู่ดี
  ผมรู้ว่าข้อจำกัดชื่ออุปกรณ์นี้ใช้กับชื่อไฟล์ของ Windows ด้วย ดังนั้นถ้าเป็นคนที่ไม่ค่อยชอบความขำขันก็คงไม่แปลกใจนัก แต่ถ้าชอบความขำขัน ก็จินตนาการแบบข้างบนได้
  ลิงก์ที่เกี่ยวข้อง: https://learn.microsoft.com/en-us/microsoftteams/limits-spec...

  • “ต้นยุค 90 มาก ๆ ที่ MS-DOS รันบน 086 หรือ 286” คลาดเคลื่อนไปประมาณ 10 ปี
    MS-DOS รันบน 8086 อยู่แล้วตั้งแต่ต้นยุค 80
  • ก็น่าประหลาดใจอยู่ดี ใน WSL คุณสร้างไฟล์แบบนั้นได้ แต่ใน Windows สร้างหรือลบไม่ได้ แบบนี้ไม่สมเหตุสมผล
    ใน Windows 10 หรือ 11 ก็ไม่มีชั้น DOS อีกต่อไปแล้ว และดูเหมือน Microsoft ไม่คิดจะแก้ปัญหาแบบนี้มากกว่า
  • ความเข้ากันได้ย้อนหลังเป็นเป้าหมายที่น่าชื่นชม และผมก็เห็นคุณค่าของความพยายามนั้น
    แต่อยากให้มันไม่รวมถึงการจำกัดรหัสผ่านให้สั้นอย่างไร้เหตุผล หรือจำกัดชุดอักขระอย่างเหลวไหลด้วย

• นึกถึงข่าวลือที่ว่าเหตุผลที่หลังจาก “Windows 7”, “8” แล้วข้าม “9” ไปเป็น “10” คือเพราะกลัวว่าใน codebase สักแห่งจะมีโค้ดแบบนี้อยู่
  if(version.StartsWith(“Windows 9”)) { /* 95 and 98 */ ... }

  • เวอร์ชัน Windows เคยถูกเปิดเผยเป็นสตริงใน Windows API ด้วยหรือ?
    ผมไม่มีประสบการณ์กับ Windows แต่รู้สึกแปลก ๆ อยู่ ด้านหนึ่ง Microsoft ก็อาจทำแบบนี้เพื่อความเข้ากันได้ย้อนหลัง แต่อีกด้านหนึ่งก็ดูเป็น API ที่แปลกที่จะให้มา
    เจอ GetVersion[1] แล้ว ซึ่งอันนี้คืนเวอร์ชันเป็นตัวเลขสองตัว
    [1] https://learn.microsoft.com/en-us/windows/win32/api/sysinfoa...

• คำต้องห้าม: forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 ถึง COM9, LPT1 ถึง LPT9, desktop.ini, _vti_

  • ตอนแรกตั้งใจจะพูดว่า “นี่แทบจะเป็นการเผลอเผยว่าข้างในมีอะไรสยอง ๆ อยู่ไม่ใช่หรือ ควรอายที่จะพูดแบบนี้ต่อสาธารณะ มันคล้ายกับบอกว่าใช้ %s หรือ $PS1 ไม่ได้ แล้วทำไมถึงไม่ได้ล่ะ? เอาอินพุตผู้ใช้ไปทำอะไรกันแน่?”
    แต่ก็อาจเป็นปัญหาเกี่ยวกับวิธีที่ชื่อช่องจะถูกจัดการในที่อื่น ๆ ก็ได้ คนอาจคัดลอกไปวางที่ไหนก็ได้ และดูเหมือนจะไม่คาดหวังให้ผู้ใช้ Windows escape สตริงของตัวเองตอนวางลงใน cmd, PowerShell, WSL
  • ช่วงกลางยุค 90 มีช่วงสั้น ๆ ที่สนุกดี ซึ่งไคลเอนต์ IRC อย่าง mIRC สามารถตั้งค่าให้ รับไฟล์อัตโนมัติ ผ่าน DCC ได้
    แล้วมันก็ยินดีเขียนลงชื่ออย่าง LPT1 ด้วย แน่นอนว่าข้อมูลนั้นก็พุ่งตรงไปยังเครื่องพิมพ์ของผู้รับทันที
  • เริ่มสงสัยว่ามีเครื่องที่มี LPT9 จริง ๆ ไหม COM9 ยังพอจินตนาการได้แบบเฉียด ๆ

• เคล็ดลับทั่วไปในการจัดโครงสร้างข้อมูลผู้ใช้คือ ถ้าเป็นไปได้ให้ปฏิบัติกับมันเหมือนเป็น ก้อนข้อมูลทึบ
  ลองนึกว่ามันถูกเข้ารหัสไว้ จึงเอาไปแสดงผลก็ไม่ได้ และมนุษย์ก็อ่านไม่ได้
  forms, CON, CONIN$, CONOUT$, PRN, AUX, NUL, COM1 ถึง COM9, LPT1 ถึง LPT9, desktop.ini, _vti_
  ถ้าจำเป็นต้องจำกัดสิ่งเหล่านี้เพราะอินพุตของผู้ใช้ถูกส่งเข้าไปยังระบบไฟล์ตรง ๆ ก็ถือว่าพลาดแล้ว ควรให้ ID ที่ปลอดภัยแทนการใช้อินพุตผู้ใช้โดยตรง อาจเป็น uuid4 หรือไดเจสต์ของชื่อช่องก็ได้
  เวลามีคนบอกว่า “ใช้อักขระนี้ไม่ได้” ผมจะมองว่ามีกลิ่นไม่ดี แล้วคิดอัตโนมัติว่า “ทำไมไม่ได้ล่ะ? คงไม่ได้เอาไปใช้เป็นข้อความธรรมดาที่ไม่ได้ encode อยู่ใช่ไหม?” ตัวอย่างเช่น รหัสผ่าน ชื่อผู้ใช้ หรือคอมเมนต์ที่จะแสดงบนหน้าเว็บ
  แต่ทั้งหมดนี้ก็อาจเป็น easter egg ที่ทำพลาดก็ได้ แค่อยากใส่ความสนุกนิดหน่อยแล้วเรื่องอาจบานปลาย

• แย่ก็จริง แต่พูดตรง ๆ เป้าหมายคืออะไร? คือการให้คนตั้งชื่ออะไรก็ได้ รวมถึงชื่อช่องด้วยงั้นหรือ? เช่นชื่ออย่าง "rm -rf /*" น่ะ
  มีแบบที่ดีกว่านั้นอีก คือเขียน rm -rf นั้นด้วยอักขระ RLO สำหรับบังคับทิศทางซ้าย-ขวา ให้ดูเหมือน fr- mr
  เราควรตั้งเป้าแบบนั้นจริงหรือ? พร้อมกับเชื่อว่าจะไม่มีปัญหาอะไรเกิดขึ้น?
  โชคดีที่บน Linux เราสร้างไฟล์ชื่อ https://example.org ไม่ได้ Windows ก็เป็นแบบนั้นไม่ใช่หรือ?
  ถ้าถามจริงจัง นี่เป็นปัญหาจริงหรือ? ถ้าเป็นปัญหา ควรขีดเส้นไว้ตรงไหน?
  แล้ว code point 0 ล่ะ? อักขระเติมเต็มภาษาเกาหลีและอักขระ RLO ล่ะ? แอปพลิเคชันที่ปฏิเสธสิ่งเหล่านี้ถือว่าแย่มากไหม?
  โชคดีที่สิ่งที่ใส่ในชื่อไฟล์ได้มีข้อจำกัดอยู่ และผมคิดว่าข้อจำกัดตอนนี้ยังไม่เข้มพอด้วยซ้ำ ชื่อผู้ใช้ ช่อง และอีกหลายอย่างก็เช่นกัน
  เช่น มีใครมองว่าเป็นปัญหาจริง ๆ ไหมที่ Twitter อนุญาตเฉพาะตัวอักษร/ตัวเลขที่มองเห็นได้กับขีดล่าง และจำกัดไม่เกิน 15 ตัวอักษร?
  ผมมองว่านี่เป็นวิธีที่ฉลาดมาก ดีกว่าการโหยหาว่าอยากใช้อีโมจิรูปอึในชื่อผู้ใช้และชื่อช่องได้มาก

  • สร้างไฟล์ชื่อ https://example.org ไม่ได้ก็จริง แต่สร้าง พาธ แบบนั้นได้แน่นอน
    เพราะ slash ซ้ำ ๆ ภายในจะถูกละเว้น และสามารถสร้างไดเรกทอรีชื่อ https: กับไฟล์ชื่อ example.org ได้
  • ถ้าจะลบข้อมูล ผมคิดว่าใช้ dd ดีกว่า rf

• ถ้าชื่อช่องถูกใช้เป็นโฟลเดอร์ SharePoint ก็น่าแปลกที่ไม่มีวิธี escape มาตรฐานสำหรับสตริงพวกนี้โดยเฉพาะ
  มันจะทำให้ความเข้ากันได้กับแอปพลิเคชันที่พึ่งพา device file แบบวิเศษเหล่านี้พัง แต่ SharePoint ไม่ควรมีเหตุผลใด ๆ ที่อยากสื่อสารกับ COM1 จริง ๆ อยู่แล้ว
  แปลกที่ SharePoint ยังไม่ได้จัดการเรื่องนี้ไว้

  • SharePoint สามารถซิงก์กับระบบไฟล์ของ Windows ได้ และ Windows/Win32 ไม่รองรับชื่อเหล่านั้นเพราะต้องรักษาความเข้ากันได้ย้อนหลัง