PowerShell , Office 365 , ไวยากรณ์ | พลังของ PowerShell | ตอนที่ 1/3 .com

เริ่มจากข้อเท็จจริงพื้นฐานเกี่ยวกับตัวฉันก่อน: ฉันไม่ใช่โปรแกรมเมอร์ (และคงจะไม่มีวันเป็นด้วย) ถ้าฉันสามารถเรียนรู้วิธีใช้ PowerShell ทุกคนก็สามารถทำได้! ในตอนแรก PowerShell ดูเหมือนเป็นเครื่องมือ “สีดำ” ที่ไม่จำเป็นและซับซ้อนสำหรับฉัน และฉันก็พยายามอย่างเต็มที่เพื่อหลีกเลี่ยงมัน

พลังของ PowerShell | บทความซีรีส์

ชุดบทความ The Power of PowerShell รวมถึงบทความสามบทความต่อไปนี้:

• พลังของ PowerShell | ตอนที่ 1/3 (บทความนี้)
• พลังของ PowerShell | ส่วนที่ 2/3
• พลังของ PowerShell | ส่วนที่ 3/3

ฉันคิดว่า: “เหตุใดฉันจึงควรใช้ PowerShell แทนที่จะเป็น Microsoft GUI (อินเทอร์เฟซผู้ใช้แบบกราฟิก) ที่เป็นมิตร เมื่อเวลาผ่านไป ฉันเริ่มตระหนักถึงข้อดีที่สำคัญของการใช้ PowerShell และเมื่อเวลาผ่านไป ฉันเริ่มรู้สึกคุ้นเคยกับสภาพแวดล้อมของ PowerShell

บทความนี้เกี่ยวกับ: ทำความรู้จักกับพื้นฐานของ PowerShell ในสภาพแวดล้อม Office 365

หากคุณรู้สึกว่าคุณต้องการเข้าใจแนวคิดและตรรกะของ PowerShell ให้ดีขึ้น และคุณยินดีที่จะจัดสรรเวลามากกว่า 2 นาทีในการอ่านข้อมูล ฉันเชื่อว่าคุณสามารถเพลิดเพลินกับความสามารถในการทำความเข้าใจสภาพแวดล้อมนี้ แทนที่จะคัดลอกและ วางคำสั่ง PowerShell “ลึกลับ”

“พาวเวอร์เชลล์” คืออะไร?

มีคำอธิบาย "เป็นทางการ" มากมายสำหรับ PowerShell แต่ขอทำให้มันง่าย: PowerShell ตามชื่อคือเป็นภาษา "Shell" และสคริปต์ ตัวละครหลักของ PowerShell เทียบกับภาษาสคริปต์อื่นๆ ก็คือ PowerShell นั้นเป็นมิตรมากและเป็นภาษาสคริปต์ "เหมือนมนุษย์"

PowerShell ช่วยให้เราใช้คำสั่งที่เรียบง่ายและทรงพลัง (cmdlets) และในขณะเดียวกัน PowerShell ก็สามารถทำหน้าที่ในการเขียนสคริปต์ที่ซับซ้อนมากได้ (นี่คือส่วนที่ใกล้เคียงกับ "โปรแกรมเมอร์") มากที่สุด

ในปัจจุบัน Microsoft OS และผลิตภัณฑ์ส่วนใหญ่สามารถจัดการได้โดยใช้ PowerShell และผลิตภัณฑ์บางอย่าง เช่น เซิร์ฟเวอร์ Exchange นั้นใช้ PowerShell ล้วนๆ

ตัวอย่างเช่น อินเทอร์เฟซ Exchange GUI ที่เราใช้เป็นเพียง "อินเทอร์เฟซที่เป็นมิตร" ทุกตัวเลือกที่เราใช้ในส่วนต่อประสาน GUI จะถูกแปลและดำเนินการเป็นคำสั่ง PowerShell

“พลัง” ของ PowerShell

มีข้อดีหลายประการของการใช้ PowerShell:

• การดำเนินการจำนวนมาก - ความหมายของคำว่า “การดำเนินการจำนวนมาก” คือความสามารถในการดำเนินการคำสั่ง PowerShell เพื่อจัดการ “กลุ่มของวัตถุ”
  ตัวอย่างเช่น เราจำเป็นต้องมอบหมายใบอนุญาตให้กับผู้ใช้ Office 365 ทั้งหมดที่ไม่มี ใบอนุญาต ในกรณีที่องค์กรของเรามีพนักงาน 10 คน สามารถดำเนินการงานนี้ได้อย่างง่ายดายโดยใช้ Office 365 Portal Web Interface แต่สถานการณ์ที่เราต้องมอบหมายใบอนุญาตให้กับผู้ใช้ 1,500 ราย
  แน่นอนว่าเราสามารถดำเนินการด้วยตนเองได้ แต่นี่จะเป็นงานที่เหนื่อยมาก
  โดยการใช้ PowerShell เราสามารถใช้ คำสั่งที่จะค้นหาผู้ใช้ทั้งหมดที่ไม่มีใบอนุญาต และมอบหมายใบอนุญาตที่จำเป็นสำหรับผู้ใช้เหล่านี้
• ส่งออกข้อมูล - อินเทอร์เฟซเว็บของ Office 365 ไม่มีตัวเลือกสำหรับการสร้างรายงานหรือส่งออกข้อมูล
  ด้วยการใช้ PowerShell เราสามารถสร้างรายงานและส่งออกข้อมูลที่จำเป็นเกี่ยวกับส่วนประกอบต่างๆ เช่น รายชื่อผู้ใช้ที่มีใบอนุญาตที่ได้รับมอบหมาย ข้อมูลเกี่ยวกับ ขนาดของกล่องจดหมาย รายชื่อผู้ใช้ที่มีข้อมูล เช่น หมายเลขโทรศัพท์ แผนก และอื่นๆ อีกมากมาย
• ไม่มีการแทรกแซงจากผู้ใช้ - เมื่อใช้ PowerShell เราสามารถดำเนินการงานการดูแลระบบที่จำเป็นทั้งหมดสำหรับผู้ใช้ Office 365 บน “พื้นหลัง” ได้โดยไม่จำเป็นต้องให้ผู้ใช้เกี่ยวข้องกับกระบวนการนี้
  ตัวอย่างเช่น เมื่อเราต้องกำหนดสิทธิ์ให้กับผู้ใช้ กล่องจดหมายหรือปฏิทินผู้ใช้ ไม่จำเป็นต้องลงชื่อเข้าใช้โปรไฟล์ผู้ใช้ Outlook หรือควบคุมเดสก์ท็อปผู้ใช้จากระยะไกล
  แต่เราสามารถดำเนินงานการจัดการที่จำเป็นได้โดยใช้คำสั่ง PowerShell แทน
• ข้อจำกัดของอินเทอร์เฟซ GUI - Office 365 Web Interface ช่วยให้เราสามารถทำงานด้านการดูแลระบบได้หลายอย่าง งานธุรการบางอย่างสามารถทำได้โดยใช้ PowerShell เท่านั้น ตัวอย่างเช่น เราสามารถใช้อินเทอร์เฟซเว็บของ Office 365 เพื่อรีเซ็ตรหัสผ่านผู้ใช้และสร้างรหัสผ่านชั่วคราวสำหรับผู้ใช้ แต่อินเทอร์เฟซบนเว็บไม่มีตัวเลือกสำหรับ : การตั้งค่ารหัสผ่านที่กำหนดไว้ล่วงหน้าสำหรับผู้ใช้ หรือเปลี่ยนนโยบายรหัสผ่านการหมดอายุเริ่มต้น (งานนี้สามารถใช้งานได้โดยใช้ PowerShell เท่านั้น)
• ทำให้งานการดูแลระบบเป็นแบบอัตโนมัติ - หลายครั้งเราจำเป็นต้องรันงานการดูแลระบบตามกำหนดเวลา
  ตัวอย่างเช่น: สร้างรายงานรายสัปดาห์ที่มีข้อมูลเกี่ยวกับผู้ใช้ใหม่ การกำหนดใบอนุญาตใหม่ ฯลฯ โดยใช้สคริปต์ PowerShell และ Windows Task Manager ในตัว เราจึงสามารถทำงานด้านการดูแลระบบเหล่านี้ได้โดยอัตโนมัติ

PowerShell ระยะไกล - Office 365

เมื่อใช้ PowerShell สำหรับ - การจัดการโครงสร้างพื้นฐาน Office 365 เราจะใช้วิธีการที่อธิบายว่าเป็น PowerShell ระยะไกล เพื่อให้สามารถดำเนินการคำสั่ง PowerShell ที่จำเป็นได้ ก่อนอื่นเราต้องสร้างเซสชันระยะไกลที่มีกระบวนการตรวจสอบสิทธิ์ไปยังโฮสต์ระยะไกล (โครงสร้างพื้นฐาน Office 365 และ Exchange Online)

เราใช้ Remote PowerShell เพื่อจัดการโครงสร้างพื้นฐานที่แตกต่างกัน 4 แบบ:

1. Office 365 - เมื่อเราใช้คำว่า “Office 365 ” ความหมายคือ: ส่วนที่ทำหน้าที่เป็น “ซองจดหมาย” ให้กับบริการ Office 365 อื่นๆ ทั้งหมด ส่วนนี้ประกอบด้วยส่วนประกอบต่างๆ เช่น: ออบเจ็กต์ผู้ใช้และกลุ่มความปลอดภัย (Windows Azure Active Directory), การจัดการชื่อโดเมน, การย้ายเมล, SSO (การลงชื่อเพียงครั้งเดียว), การจัดการใบอนุญาต และอื่นๆ
2. Exchange Online - ส่วนนี้รวมถึงการจัดการบริการ Mail เช่น เพิ่มหรือลบที่อยู่อีเมล กำหนดขนาดกล่องจดหมาย กำหนดนโยบายให้กับกล่องจดหมาย เป็นต้น
3. แชร์พอร์ตออนไลน์
4. ลินคอล์นออนไลน์

โครงสร้างพื้นฐาน Office 365 แต่ละรายการจำเป็นต้องมี "เซสชัน PowerShell ระยะไกลเฉพาะ" และสำหรับแต่ละสภาพแวดล้อมเหล่านี้ เราจำเป็นต้องใช้ชุด cmdlets ที่แตกต่างกัน (เราจะตรวจสอบคำว่า cmdlets ในภายหลัง) เพื่อสร้างเซสชันระยะไกล

PowerShell “คลาสวัตถุ”

PowerShell เป็นเรื่องเกี่ยวกับ: การจัดการออบเจ็กต์
ในสภาพแวดล้อม Office 365 มีออบเจ็กต์มากมาย ตัวอย่างของ “วัตถุ” อาจเป็น: ผู้ใช้, กล่องจดหมาย, กลุ่ม, โดเมน ฯลฯ

คลาส/ประเภทของวัตถุและอินสแตนซ์ของวัตถุ

คำว่า "คลาส/ประเภทวัตถุ " อธิบาย "เอนทิตี " ที่มีคุณสมบัติเฉพาะ เมื่อเราสร้าง “ออบเจ็กต์ใหม่” เช่น: ผู้ใช้ใหม่ จริงๆ แล้วเรากำลังสร้าง ออบเจ็กต์อินสแตนซ์

”อินสแตนซ์ใหม่” (เช่น ผู้ใช้ใหม่) สืบทอดโครงสร้างของคลาสอ็อบเจ็กต์ และ (โดยส่วนใหญ่) จะมีเอกลักษณ์เฉพาะตัว

ตัวอย่างเช่น: เมื่อเราสร้างผู้ใช้ใหม่ชื่อ “John ” ผู้ใช้ใหม่จะถือว่าเป็น “อินสแตนซ์ ” ของคลาสอ็อบเจ็กต์ “User ” ผู้ใช้ใหม่ (John) จะมี "ฟิลด์คุณสมบัติ" ทั้งหมดที่สืบทอดมาจากคลาสอ็อบเจ็กต์ผู้ใช้

หมายเหตุ: โดยส่วนใหญ่แล้ว เราไม่ได้ใช้คำว่า “อินสแตนซ์ ” เมื่อพูดถึงวัตถุ แต่เราเพียงใช้คำว่า “วัตถุ” แทน ”

คลาสอ็อบเจ็กต์และอนุพันธ์ของอ็อบเจ็กต์

"คลาสวัตถุ" บางส่วนทำหน้าที่เป็น "วัตถุรูท" ที่มีอนุพันธ์

ตัวอย่างเช่น - “Group Object Class” มีอนุพันธ์ดังต่อไปนี้:

ออบเจ็กต์กลุ่มอาจเป็น: กลุ่มความปลอดภัยหรือกลุ่มการแจกจ่าย และกลุ่มการแจกจ่าย อาจเป็น "กลุ่มการแจกจ่ายมาตรฐาน" หรือกลุ่มการแจกจ่ายแบบไดนามิก

เมื่อเราสร้าง “กลุ่มการแจกจ่าย” ใหม่ อินสแตนซ์ใหม่จะสืบทอดโครงสร้างและคุณสมบัติของ “คลาสอ็อบเจ็กต์กลุ่ม” + คุณสมบัติเฉพาะ ซึ่งไม่ซ้ำกันสำหรับคลาสอ็อบเจ็กต์ “กลุ่มการแจกจ่าย” เช่น: ที่อยู่อีเมลและการอนุมัติข้อความ .

คุณสมบัติของวัตถุ

คำจำกัดความพื้นฐานสำหรับคลาสอ็อบเจ็กต์อาจเป็น: คอลเลกชันหรือชุดคุณสมบัติที่กำหนดไว้ล่วงหน้า
แนวคิดของอ็อบเจ็กต์และคุณสมบัติของอ็อบเจ็กต์นั้น "ยืม" จากโลกแห่งความเป็นจริง

ตัวอย่างเช่น - เราแต่ละคน (มนุษย์หรือบุคคล) มีคุณสมบัติเช่น - ส่วนสูง สีตา น้ำหนัก สัญชาติ เป็นต้น

แต่ละคลาสอ็อบเจ็กต์ เช่น อ็อบเจ็กต์ผู้ใช้หรืออ็อบเจ็กต์กล่องจดหมาย มีชุดคุณสมบัติเฉพาะที่ "เกี่ยวข้อง" กับคลาสอ็อบเจ็กต์

ตัวอย่างเช่น คุณสมบัติออบเจ็กต์ผู้ใช้อาจเป็น: รายละเอียดทั่วไป เช่น - ตำแหน่ง แผนก เมือง หมายเลขโทรศัพท์ หรือคุณสมบัติอื่นๆ เช่น: บทบาทผู้ใช้ (ผู้ใช้มาตรฐาน ผู้ดูแลระบบส่วนกลาง) ใบอนุญาต (ผู้ใช้มีหรือไม่มี ใบอนุญาต), กล่องจดหมาย (ผู้ใช้มีกล่องจดหมาย "แนบ" กับบัญชีผู้ใช้ของเขาหรือไม่) เป็นต้น

หมายเหตุ: กล่องจดหมายอาจถือเป็น "วัตถุ" ได้ แต่กล่องจดหมายก็ถือเป็น "คุณสมบัติ" ของผู้ใช้ด้วย เนื่องจากวัตถุกล่องจดหมายไม่มี "ชีวิตในตัวเอง ” วัตถุกล่องจดหมายควร "แนบ" กับวัตถุผู้ใช้

ตัวอย่างเพิ่มเติมคือ - คุณสมบัติกล่องจดหมาย

คุณสมบัติของออบเจ็กต์กล่องจดหมายอาจเป็นขนาดกล่องจดหมาย ที่อยู่อีเมลที่ "แนบ" กับกล่องจดหมาย การเก็บถาวรส่วนบุคคล ฯลฯ

“คุณสมบัติกล่องจดหมาย” เพิ่มเติมอาจเป็นนโยบายที่แนบมากับกล่องจดหมาย

ตัวอย่างเช่น: นโยบายการเก็บรักษา (นโยบายที่เกี่ยวข้องกับการลบหรือย้ายไปยังรายการเมลที่เก็บถาวรเมื่อรายการเมลถึง "อายุ" ที่เฉพาะเจาะจง)

ในกรณีที่เราต้องการแสดงรายการคุณสมบัติที่ "เป็น" ของคลาสอ็อบเจ็กต์เฉพาะ เราสามารถใช้ PowerShell cmdlets:

Get-Object Class | Get-Member

ค่าคุณสมบัติของวัตถุ

ดังที่ได้กล่าวไปแล้ว เราสามารถอธิบายอ็อบเจ็กต์ว่าเป็นชุดของคุณสมบัติได้ เมื่อเราสร้างออบเจ็กต์ใหม่ (หรือหากเราต้องการให้มีความแม่นยำมากขึ้น - อินสแตนซ์ของออบเจ็กต์) คุณสมบัติบางอย่าง “ต้อง” มีค่า (ข้อกำหนดบังคับ)

ตัวอย่างเช่น: วัตถุผู้ใช้ Office 365 ต้องมีชื่อนามแฝงและชื่อหลักของผู้ใช้ คุณสมบัติอื่นๆ เช่น: รหัสผ่านไม่มีวันหมดอายุ จะถูกตั้งค่าโดยอัตโนมัติด้วยค่า “True ” และคุณสมบัติเพิ่มเติม เช่น ตำแหน่ง แผนก เมือง และอื่นๆ ไม่มีค่าที่กำหนดไว้ล่วงหน้า (หรือเราอาจพูดว่า: “คุณสมบัติว่างเปล่า”)

“ค่า” นี้สามารถตั้งค่าได้โดยผู้ดูแลระบบที่จัดการบัญชีของผู้ใช้

วัตถุอ้างอิง

ส่วนแรกสำหรับทุก “ประโยค PowerShell ” หรือคำสั่ง PowerShell จะเริ่มต้นด้วยการอ้างอิงถึงคลาสอ็อบเจ็กต์หรืออินสแตนซ์ของอ็อบเจ็กต์ เรามาตรวจสอบตัวเลือกสำหรับ “วัตถุอ้างอิง” โดยการสาธิตงานการดูแลระบบพื้นฐานของการจัดการกล่องจดหมาย

เมื่อเราต้องการจัดการกล่องจดหมายที่โฮสต์บนเซิร์ฟเวอร์ Exchange Online เราสามารถกำหนด 3 ตัวเลือกสำหรับวัตถุ "อ้างอิง":

1. อ้างอิงถึงอินสแตนซ์เฉพาะของคลาสอ็อบเจ็กต์
   ตัวอย่างเช่น - เราต้องการรับข้อมูลเกี่ยวกับกล่องจดหมาย “John ”
2. คลาสอ็อบเจ็กต์อ้างอิง
   เราสามารถใช้คำสั่ง PowerShell ที่แสดงข้อมูลเกี่ยวกับคลาสอ็อบเจ็กต์กล่องจดหมายทั้งหมด
3. การอ้างอิงเซ็ตย่อย/กลุ่มของอ็อบเจ็กต์
   ในสภาพแวดล้อม Exchange เรามี "กล่องจดหมาย" ประเภทอื่น เช่น กล่องจดหมายของผู้ใช้ กล่องจดหมายของทรัพยากร กล่องจดหมายที่ใช้ร่วมกัน กล่องจดหมายค้นหา เป็นต้น หลายครั้งเราต้องการอ้างอิงเฉพาะ "เซ็ตย่อย" หรือ “กลุ่มย่อย” ของออบเจ็กต์

ตัวอย่างเช่น: เราต้องการแสดงเฉพาะกล่องจดหมายที่ "เป็น" ของกลุ่ม "กล่องจดหมายของผู้ใช้"

วัตถุ “อัตลักษณ์”

เมื่อเราต้องการอ้างอิง “อินสแตนซ์ ” ของคลาสอ็อบเจ็กต์ เราจะต้องระบุ เอกลักษณ์ของวัตถุ แนวคิดของ: “ตัวตน ” นี้คล้ายกับ “โลกแห่งความจริง ” มาก

เราแต่ละคนมีตัวตนสองสามอย่าง เช่น - ชื่อจริง ชื่อเต็ม “ชื่อเล่น” หรือหมายเลขโซเชียล ในทำนองเดียวกัน เมื่อเราต้องจัดการอินสแตนซ์เฉพาะของออบเจ็กต์ เช่น “บัญชีผู้ใช้ John” เราจำเป็นต้องระบุข้อมูลประจำตัวของอินสแตนซ์นี้ (John)

หมายเหตุ: “ข้อมูลระบุตัวตน” ส่วนใหญ่ถือเป็น “ไม่ซ้ำกัน” ซึ่งหมายความว่า ไม่มีวัตถุอื่น (ผู้ใช้) ที่สามารถมีเอกลักษณ์เดียวกันได้

วัตถุผู้ใช้ “ตัวตน”

เพื่อจุดประสงค์ในการสาธิต เรามาตรวจสอบตัวเลือกสำหรับ “User Object Identities ” รายการต่อไปนี้ประกอบด้วยคำอธิบายของ User Object Identities ต่างๆ ที่เราสามารถใช้ได้เมื่อเราต้องการอ้างอิงอินสแตนซ์เฉพาะของคลาสอ็อบเจ็กต์ (ผู้ใช้เฉพาะ เช่น “John”

• ชื่อที่แสดงของผู้ใช้ - ข้อมูลประจำตัวนี้ประกอบด้วยชื่อผู้ใช้และชื่อผู้ใช้สุดท้าย ตัวระบุ “ชื่อที่แสดง” ไม่ใช่ตัวระบุเฉพาะ ความหมายคือ เราสามารถมีผู้ใช้ได้ 2 คน (หรือมากกว่า) ที่มีชื่อที่แสดงเหมือนกัน
  เมื่อเราต้องการอ้างอิงวัตถุโดยใช้ชื่อที่แสดงของวัตถุ เราควรใช้เครื่องหมายคำพูดเนื่องจากชื่อที่แสดงมีการเว้นวรรค ( ช่องว่างระหว่างชื่อและนามสกุล) เนื่องจากข้อมูลระบุตัวตนของผู้ใช้ "ชื่อที่แสดง" นั้นไม่ซ้ำกัน เราจึงแนะนำให้หลีกเลี่ยงตัวเลือกนี้เมื่อเราต้องการอ้างอิงถึงผู้ใช้รายใดรายหนึ่ง
• User UPN - (UPN ย่อมาจาก - ชื่อหลักของผู้ใช้) ใน Office 365 ผู้ใช้ UPN=ชื่อเข้าสู่ระบบของผู้ใช้ User UPN เป็นตัวระบุที่ไม่ซ้ำกัน (ผู้ใช้เพียงคนเดียวเท่านั้นที่สามารถมี UPN ที่เฉพาะเจาะจงได้) UPN ประกอบด้วยชื่อนามแฝงของผู้ใช้และโดเมนผู้เช่า Office หรือชื่อ “โดเมนแบบกำหนดเอง” (ชื่อโดเมนแบบสื่อความหมาย)
  ตามค่าเริ่มต้น UPN ของผู้ใช้จะเป็นที่อยู่อีเมลหลักของผู้ใช้ด้วย (ค่าเริ่มต้นนี้สามารถ เปลี่ยนแปลงได้โดยใช้คำสั่ง PowerShell เท่านั้น)
• นามแฝงผู้ใช้ - ชื่อนามแฝงของผู้ใช้ที่สร้างขึ้นตามองค์กร “นโยบายชื่อนามแฝง”
  ตัวอย่างเช่น นโยบายชื่อนามแฝงมาตรฐานอาจเป็นชื่อจริงของผู้ใช้และอักขระตัวแรกของชื่อผู้ใช้ของครอบครัว ชื่อนามแฝงของผู้ใช้ไม่ใช่ตัวระบุเฉพาะ เมื่อเราต้องการอ้างอิงกล่องจดหมายของผู้ใช้ การใช้ชื่อนามแฝงของผู้ใช้แทนการใช้ UPN ผู้ใช้ "แบบยาว" จะง่ายกว่า
• ที่อยู่อีเมลของผู้ใช้ - ที่อยู่อีเมลของผู้ใช้เป็นตัวระบุที่ไม่ซ้ำกัน เมื่อผู้ใช้ Office 365 มีกล่องจดหมาย ผู้ใช้จะต้องมีที่อยู่อีเมลอย่างน้อยหนึ่งรายการที่อธิบายว่าเป็นที่อยู่อีเมลหลัก ตามที่กล่าวไว้ โดยค่าเริ่มต้น ที่อยู่อีเมลหลักของผู้ใช้จะเหมือนกับ UPN ของผู้ใช้
• GUID (ID วัตถุ) - ID วัตถุเป็นตัวระบุที่ไม่ซ้ำกัน ตัวระบุนี้ไม่ได้ใช้บ่อยนัก ครั้งเดียวที่เราต้องใช้ "รหัสวัตถุ" คือเมื่อเราจำเป็นต้องใช้การกำหนดค่าเฉพาะที่เกี่ยวข้องกับกลุ่มความปลอดภัย

หมายเหตุ: มี "ข้อมูลระบุตัวตน" เพิ่มเติม เช่น ที่อยู่ SIP (ที่อยู่ LYNC ของผู้ใช้) และที่อยู่ Windows Live ID แต่เราจะ "ข้าม" "ข้อมูลระบุตัวตน" เหล่านี้ เนื่องจากไม่ได้ใช้บ่อยนัก

วัตถุผู้ใช้ในสภาพแวดล้อม Office 365

Office 365 สามารถนิยามได้ว่าเป็น “ชุดบริการคลาวด์”

เมื่อใช้การดูแลพอร์ทัล Office 365 (อินเทอร์เฟซเว็บ) โครงสร้างพื้นฐานที่แตกต่างกันจะดูเหมือน "เอนทิตีเดียว" แต่ในความเป็นจริงแล้ว แต่ละบริการเหล่านี้ (Windows Azure Active Directory, Exchange Online ฯลฯ) จะขึ้นอยู่กับบริการที่แยกจากกัน โครงสร้างพื้นฐานที่มีฟอเรสต์ Active Directory เฉพาะ เซิร์ฟเวอร์เฉพาะ และอื่นๆ

ตัวอย่างเช่น: เมื่อเราสร้างบัญชีผู้ใช้ใหม่ บัญชีผู้ใช้จะถูกสร้างขึ้นใน Windows Azure Active Directory จากนั้น สำเนาของบัญชีผู้ใช้จะถูกจำลองแบบไปยังบริการ/โครงสร้างพื้นฐานเพิ่มเติมทั้งหมด เช่น Exchange Online, SharePoint online และ LYNC ออนไลน์

เมื่อเราอ้างอิงวัตถุเช่น: “วัตถุผู้ใช้” เราจำเป็นต้องรู้ว่าโครงสร้างพื้นฐานใดที่เราต้องการอ้างอิง

ไวยากรณ์คำสั่ง PowerShell และ “กฎ” สำหรับการอ้างอิงวัตถุ “ข้อมูลประจำตัว” จะแตกต่างกันเล็กน้อยเมื่อเราอ้างอิงวัตถุในสภาพแวดล้อม Office 365 (Windows Azure Active Directory) กับโครงสร้างพื้นฐาน Exchange Online

1. การอ้างอิงวัตถุผู้ใช้ใน Office 365 (Azure Active Directory) - ชื่อวัตถุ PowerShell ที่เราใช้ เมื่อเราต้องการจัดการวัตถุผู้ใช้ในโครงสร้างพื้นฐาน Office 365 คือ: MsolUser
2. การอ้างอิงวัตถุผู้ใช้ใน Exchange Online - ชื่อวัตถุผู้ใช้ PowerShell ที่เราใช้เมื่อเราต้องการจัดการวัตถุผู้ใช้ในโครงสร้างพื้นฐาน Exchange Online คือ: “ผู้ใช้ ”

PowerShell และการจัดการวัตถุ

ในส่วนถัดไป เราจะ "เจาะลึก" เข้าไปในคำสั่ง PowerShell และไวยากรณ์คำสั่ง PowerShell เฉพาะ แต่ก่อนที่เราจะเริ่ม เราจะสรุป:

เราใช้ PowerShell เพื่อจัดการออบเจ็กต์ “การจัดการวัตถุ” อาจเป็น:

• สร้างหรือลบออบเจ็กต์ - การสร้างอินสแตนซ์ออบเจ็กต์ใหม่ เช่น บัญชีผู้ใช้ บัญชีกลุ่ม หรือการลบออบเจ็กต์ที่มีอยู่
• การแก้ไขคุณสมบัติของออบเจ็กต์ - โดยการเพิ่มค่าใหม่ให้กับคุณสมบัติของออบเจ็กต์ เช่น ชื่อของแผนก ตำแหน่ง เพิ่มใบอนุญาต เพิ่มหรือลบสิทธิ์ ฯลฯ
• “ดึงข้อมูล ” และแสดงข้อมูลเกี่ยวกับออบเจ็กต์ - เมื่อเราต้องการจัดการออบเจ็กต์ เราจะใช้คำสั่ง PowerShell เพื่ออ้างอิงถึงคลาสออบเจ็กต์เฉพาะ เช่น คลาสออบเจ็กต์ User หรือ Mailbox เมื่อเราต้องการอ้างอิงอินสแตนซ์ออบเจ็กต์เฉพาะ เราจำเป็นต้องใช้ออบเจ็กต์ ข้อมูลประจำตัวข้อมูลที่เราต้องการได้รับเกี่ยวกับวัตถุสามารถแสดงบนหน้าจอ (คอนโซล PowerShell) หรือสามารถส่งออกเป็นไฟล์เพื่อวัตถุประสงค์ในการสร้างรายงานหรือเพื่อวัตถุประสงค์ในการแก้ไขข้อมูลที่ส่งออก

cmdlet ของ PowerShell

คำจำกัดความอย่างเป็นทางการสำหรับ cmdlets คือ:

“ใน PowerShell งานการดูแลระบบจะดำเนินการโดย cmdlets (ออกเสียงว่า command-lets) Cmdlets เป็นคลาสเฉพาะของ NET ที่ใช้การดำเนินการเฉพาะ ชุด cmdlet อาจรวมกับสคริปต์ โปรแกรมปฏิบัติการ (ซึ่งเป็นแอปพลิเคชันแบบสแตนด์อโลน) หรือโดยการสร้างอินสแตนซ์คลาสปกติของ NET (หรือวัตถุ WMI/COM) สิ่งเหล่านี้ทำงานโดยการเข้าถึงข้อมูลในที่เก็บข้อมูลต่างๆ เช่น ระบบไฟล์หรือรีจิสทรี ซึ่งเปิดให้รันไทม์ของ PowerShell ผ่านทางผู้ให้บริการ Windows PowerShell ”

ตอนนี้ เรามาลองอธิบายความหมายของ cmdlets โดยใช้คำอธิบายที่เป็นมิตรมากขึ้น: PowerShell cmdlets คือ “คำสั่งเล็กๆ น้อยๆ” ”

(ฉันคิดว่านี่คือความหมายของคำต่อท้าย "ให้") ที่เราใช้สำหรับจัดการวัตถุในสภาพแวดล้อม PowerShell แนวคิดของ “cmdlets” เป็นลักษณะเฉพาะของภาษา PowerShell เทียบกับภาษาสคริปต์อื่น

เราสามารถเกี่ยวข้องกับ “cmdlets” ว่าเป็น “แอปพลิเคชันขนาดเล็ก” หรือ “แอป” (เช่น แอปที่เราใช้บนอุปกรณ์เคลื่อนที่) แต่ละคลาสอ็อบเจ็กต์ เช่น คลาสอ็อบเจ็กต์ User มีชุด cmdlets “เฉพาะ” ที่ช่วยให้เราสามารถจัดการอ็อบเจ็กต์ด้วยวิธีที่ง่ายและ “เป็นมิตร”

PowerShell และปัญหาของ Case Sensitive

สภาพแวดล้อม PowerShell ไม่ถือว่าคำนึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ เมื่อเราใช้อักษรตัวพิมพ์ใหญ่สำหรับชื่อ PowerShell cmdlets หรือของชื่อคุณสมบัติ นี่เป็นเพียงเพื่อวัตถุประสงค์ "สุนทรียภาพ" เท่านั้น

Cmdlets - แบบแผนการตั้งชื่อ

ชื่อ Cmdlets สร้างขึ้นจาก "ส่วน" สองส่วนคั่นด้วยยัติภังค์:

• ส่วนแรกของชื่อ cmdlets จะขึ้นต้นด้วย “กริยา” เช่น Set, Get เป็นต้น
• ส่วนที่สองของชื่อ cmdlets คือชื่อคลาส/ประเภทวัตถุ เช่น: ผู้ใช้ กล่องจดหมาย กลุ่ม ฯลฯ
• “กริยา ” และชื่อวัตถุ “เชื่อมต่อ” กับอักขระ “ยัติภังค์ ” (ไม่มีช่องว่างระหว่างชื่อ “กริยา ” และชื่อ “วัตถุ ”

1. “คำกริยา ” (คำนำหน้า)

“กริยา” “ยอดนิยม” “กริยา” ที่เราใช้บ่อยที่สุดได้แก่:

• ใหม่ - cmdlet ที่ขึ้นต้นด้วยคำนำหน้า “ใหม่ ” ใช้สำหรับ: การสร้างวัตถุใหม่ ตัวอย่างเช่น: สร้างผู้ใช้ Office 365 ใหม่
• ชุด - cmdlets ที่ขึ้นต้นด้วยคำนำหน้า “Set ” ใช้สำหรับ: อัปเดตคุณสมบัติของวัตถุ “อัปเดต” สามารถใช้งานได้โดย - เพิ่มค่าใหม่ให้กับออบเจ็กต์ หรืออัปเดตคุณสมบัติของออบเจ็กต์ที่มีอยู่
• เพิ่ม - cmdlets ที่ขึ้นต้นด้วยคำนำหน้า “เพิ่ม ” ใช้สำหรับ: “เพิ่ม “บางสิ่ง” ให้กับวัตถุ ตัวอย่างเช่น: เพิ่มผู้ใช้ในกลุ่มการแจกจ่าย เพิ่มนามแฝงในกล่องจดหมาย เพิ่มสิทธิ์ของกล่องจดหมาย ฯลฯ
• ลบ - cmdlet ที่ขึ้นต้นด้วยคำนำหน้า “Remove ” ใช้สำหรับ: ลบหรือลบวัตถุ หรือลบ “บางสิ่ง” ออกจากวัตถุ ตัวอย่างเช่น - ลบ (ลบ) บัญชีผู้ใช้ Office 365 หรือลบสิทธิ์ของกล่องจดหมาย
• รับ - PowerShell Cmdlets ที่ขึ้นต้นด้วยคำนำหน้า “Get ” ใช้สำหรับ: ดึงข้อมูลหรือ “ดึงข้อมูล” วัตถุ คำนำหน้า "Get " มีความพิเศษเนื่องจากเราสามารถใช้ "Get cmdlets " เพื่อแสดงข้อมูลเกี่ยวกับวัตถุ หรือเราสามารถใช้ "Get cmdlets " เป็น "ส่วนแรก" ของประโยค PowerShell “ส่วนถัดไป” ของประโยค PowerShell จะขึ้นอยู่กับ “อินพุต” ที่เราได้รับจาก “Get cmdlets”

<แข็งแกร่ง>2. “คำนาม”

“คำนาม” เป็นส่วนที่สองของชื่อ cmdlets ในโลกของ PowerShell คำนามคือชื่อของคลาสอ็อบเจ็กต์ เช่น ผู้ใช้ กลุ่ม กล่องจดหมาย เป็นต้น

วัตถุและเป็น cmdlets เฉพาะ

ในภาษา PowerShell แต่ละออบเจ็กต์จะมี “ชุด cmdlets เฉพาะ” ซึ่งสร้างขึ้นเพื่อการจัดการออบเจ็กต์เฉพาะนี้โดยเฉพาะ

ตัวอย่างเช่น: ชื่อวัตถุที่แสดงถึงวัตถุผู้ใช้ใน Office 365 คือ: MsolUser

PowerShell cmdlets สำหรับ Office 365 มี “ชุด cmdlets” เฉพาะที่เราใช้สำหรับจัดการออบเจ็กต์ผู้ใช้ เช่น:

• Get-MsolUser - สำหรับแสดงข้อมูลเกี่ยวกับผู้ใช้ Office 365
• Remove-MsolUser - สำหรับการลบบัญชีผู้ใช้
• New-MsolUser - สำหรับการสร้างบัญชีผู้ใช้ Office 365 ใหม่

หลักการเดียวกันนี้ถูกนำไปใช้กับออบเจ็กต์อื่นๆ ทั้งหมด เช่น: ออบเจ็กต์กล่องจดหมาย, ออบเจ็กต์กลุ่ม และอื่นๆ

การใช้ Get-Help cmdlets

ในบทความนี้ เราจะตรวจทานเพียงส่วนเล็กๆ ของ Office 365 และ Exchange Online cmdlet ที่พร้อมใช้งาน และตัวอย่างที่เราใช้เปิดเผยเพียง “พื้นผิว” ของพารามิเตอร์และตัวเลือกนั้นสำหรับแต่ละ cmdlet ของ

โดยใช้ cmdlets: Get-Help เราจะได้รับข้อมูลเกี่ยวกับ cmdlets ที่พร้อมใช้งานที่เราสามารถใช้ได้ และรับข้อมูลเกี่ยวกับ cmdlet ที่เฉพาะเจาะจง

ตัวอย่างที่ 1 - แสดง cmdlets ที่ตั้งค่าไว้สำหรับคลาสอ็อบเจ็กต์: MsolUser

หากต้องการรับรายการ Cmdlets ทั้งหมดที่เกี่ยวข้องกับ “วัตถุ”: MsolUser เราสามารถใช้คำสั่งต่อไปนี้:

Get-Help *MsolUser*

ตัวอย่างที่ 2 - แสดงข้อมูลวิธีใช้สำหรับ cmdlet เฉพาะ

หากเราต้องการรับข้อมูลเกี่ยวกับวิธีที่เราสามารถใช้ cmdlet เฉพาะ (พารามิเตอร์ ไวยากรณ์ ฯลฯ) เราสามารถใช้ Get-Help cmdlets กับชื่อของ cmdlet ที่เราสนใจ

ตัวอย่างเช่น: สำหรับการแสดงข้อมูลความช่วยเหลือเกี่ยวกับ Get-MsolUser cmdlet เราสามารถใช้คำสั่งต่อไปนี้:

Get-Help Get-MsolUser

ลำดับชั้นของวัตถุและชื่อ cmdlets

แนวคิด PowerShell อีกแนวคิดหนึ่งที่ฉันอยากจะเน้นย้ำคือสิ่งที่ฉันเรียกว่า "ลำดับชั้นของวัตถุ ” คำว่า “ลำดับชั้น” อธิบายความสัมพันธ์ระหว่าง “ผู้ปกครองและเด็ก” ระหว่างคลาสอ็อบเจ็กต์

เพื่อสาธิตแนวคิด "ลำดับชั้นของวัตถุ" เรามาสังเกตวัตถุกล่องจดหมายกัน
วัตถุกล่องจดหมายทำหน้าที่เป็น "คอนเทนเนอร์" สำหรับโฟลเดอร์ อีกวิธีในการอธิบายความสัมพันธ์นี้คือการพูดว่า: วัตถุกล่องจดหมายคือ "พาเรนต์" ของวัตถุโฟลเดอร์ (หรือเราสามารถพูดได้ว่าโฟลเดอร์นั้นเป็น "ลูก" ของวัตถุกล่องจดหมาย)

ออบเจ็กต์โฟลเดอร์คือ "พาเรนต์" ของโฟลเดอร์ย่อยเพิ่มเติม เช่น โฟลเดอร์ "รายการที่ส่ง", โฟลเดอร์ "ปฏิทิน", โฟลเดอร์ "ผู้ติดต่อ" และอื่นๆ

หากเราต้องการให้ "ลึกขึ้น" ในลำดับชั้น โฟลเดอร์เช่น "รายการที่ส่ง" อาจมีโฟลเดอร์เพิ่มเติม และ "ระดับต่ำสุด" อาจเป็น "รายการจดหมาย"

แนวคิดของ "ลำดับชั้นของวัตถุ" แสดงโดยชื่อ cmdlets และตามไวยากรณ์ PowerShell ที่เราใช้

สมมติว่าเราจำเป็นต้องได้รับข้อมูลเกี่ยวกับสิทธิ์สำหรับโฟลเดอร์ปฏิทินของผู้ใช้รายใดรายหนึ่ง cmdlet ที่เราใช้เพื่อจุดประสงค์นี้คือ:

Get-MailboxFolderPermission

คุณจะสังเกตเห็นว่า “ชื่อ cmdlet” อธิบายลำดับชั้นหรือ “ความสัมพันธ์” ที่มีอยู่ระหว่างวัตถุกล่องจดหมายที่ทำหน้าที่เป็น “พาเรนต์” ไปยังวัตถุ “โฟลเดอร์” และ “สิทธิ์” ที่เกี่ยวข้องกับวัตถุโฟลเดอร์

ไวยากรณ์คำสั่ง PowerShell ที่เราใช้สำหรับแสดงข้อมูลสิทธิ์เกี่ยวกับปฏิทินผู้ใช้คือ:

เราใช้ cmdlets “Get-MailboxFolderPermission” สำหรับ: รับข้อมูลสิทธิ์เกี่ยวกับโฟลเดอร์ จากนั้น เราระบุข้อมูลประจำตัวผู้ใช้ (เช่น John) และสุดท้าย เราระบุชื่อโฟลเดอร์เฉพาะ (โฟลเดอร์ปฏิทินในตัวอย่างของเรา)

หากเราต้องการข้อมูลเพิ่มเติมเกี่ยวกับ cmdlet ที่มีอยู่ที่เราสามารถใช้จัดการโฟลเดอร์ได้ ออบเจ็กต์เราสามารถใช้ Get-Help cmdlet ได้ด้วยวิธีต่อไปนี้:

Get-Help *Folder*

ในภาพหน้าจอ เราจะเห็นรายการ cmdlets ทั้งหมดที่เกี่ยวข้องกับ “Folder Object”

อย่างที่คุณเห็น เราสามารถจัดการ "แง่มุมต่างๆ" ของออบเจ็กต์โฟลเดอร์ได้ เช่น สิทธิ์ของโฟลเดอร์ สถิติของโฟลเดอร์ และอื่นๆ

ข้อสังเกตที่น่าสนใจอีกประการหนึ่งที่เราเห็นคือเรามี cmdlets “เฉพาะ” สำหรับโฟลเดอร์ปฏิทิน (Get-MailboxCalenderFolder)

ตามเหตุผลแล้ว “โฟลเดอร์ปฏิทิน” ควรได้รับการ “ปฏิบัติ” เช่นเดียวกับโฟลเดอร์อื่นๆ แต่เนื่องจากโฟลเดอร์ปฏิทินเป็นคุณลักษณะที่สำคัญของกล่องจดหมาย Exchange เราจึงมี cmdlets “พิเศษ” ที่เราใช้สำหรับรับข้อมูลเกี่ยวกับคุณสมบัติของปฏิทิน เช่น: PublishDateRange, DetailLevel และอื่นๆ

การวางท่อ

แนวคิดของ "Pipeling" เป็นหนึ่งใน "Foundation stone" ของภาษา PowerShell แนวคิดการวางท่อคล้ายคลึงกับประโยคของมนุษย์ที่ประกอบด้วยสองส่วน แต่ละ "ส่วน" ในประโยค "นำไปสู่" ไปยัง "ส่วนถัดไป"

เพื่อให้แนวคิดเรื่อง Pipeling ง่ายขึ้น มาดูคำแนะนำต่อไปนี้ใน: “วิธีทำไข่กวน ”

• ไปที่ร้านขายของชำแล้วซื้อไข่หนึ่งกล่อง
• ตอกไข่และเทไข่ลงในกระทะ
• ตอกไข่.
• เมื่อไข่เจียวพร้อมแล้ว ให้นำไข่เจียวใส่จาน

ตอนนี้เรามาดูคำแนะนำอีกครั้ง:

การผ่าตัดครั้งแรกคือ: ไปที่ร้านขายของชำ ร้านขายของชำมีสินค้า (สิ่งของ) หลายประเภท เช่น ขนมปัง น้ำตาล และอื่นๆ ในสถานการณ์ของเรา เราสนใจเฉพาะวัตถุบางประเภทเท่านั้น ซึ่งก็คือ ไข่ ส่วนแรกของประโยค “leads” ไปยังส่วนถัดไปของประโยค

ส่วนถัดไปประกอบด้วยคำแนะนำเกี่ยวกับ “จะทำอย่างไรกับไข่” เราสามารถพูดได้ว่าส่วนที่ 2 นั้นขึ้นอยู่กับ "อินพุต" ของส่วนที่ 1 เพราะเราไม่สามารถ "ตอกไข่แล้วหกไข่ลงกระทะ" ได้ ถ้าส่วนแรกยังทำไม่เสร็จ (ซื้อ/รับไข่)

ตรรกะเดียวกันนี้ใช้กับส่วนที่สามของประโยค (การแย่งไข่) เพราะก่อนที่เราจะแย่งไข่ได้ เราต้องตอกไข่และเทไข่ลงในกระทะก่อน

อาจไม่ใช่ตัวอย่างที่ยอดเยี่ยมที่สุด แต่นี่เป็นวิธีที่แน่นอนที่ Pipeling ทำงานใน PowerShell ในสภาพแวดล้อม PowerShell เราใช้ "Pipeling " สำหรับ "การสร้าง " ประโยค PowerShell แต่ละส่วนของประโยค PowerShell จะ “แยก” ออกจากส่วนอื่นๆ โดยใช้อักขระไปป์ (“| ”)

ชื่อ “ท่อ” ถูกเลือกมาเป็นอุปมาเพราะ “ท่อ” ทำหน้าที่เป็น “ภาชนะ” แทน “ของเหลว” เช่น น้ำ (ข้อมูล) ที่เราต้องการเส้นทางจากจุด A ไปยังจุด B

เมื่อเราใช้ "ไปป์" "เนื้อหา" ของส่วนแรกของประโยค PowerShell จะถูกส่งผ่าน "ไปป์" ไปยังส่วนที่สองของประโยค PowerShell ในส่วนที่สอง เรา "ทำบางสิ่งบางอย่าง" ด้วยอินพุตจากส่วนแรก และเราสามารถ "กำหนดเส้นทาง" อินพุต (ข้อมูล) ต่อไปผ่าน "ไปป์เพิ่มเติม" ไปยังส่วนถัดไป และอื่นๆ

ไม่มีการจำกัด "จำนวนส่วน" ในประโยค PowerShell เราสามารถใช้ประโยค PowerShell ง่ายๆ ที่มีเพียงส่วนเดียว (ไม่มีไปป์) หรือเราสามารถสร้างประโยค PowerShell ที่ซับซ้อนมากซึ่งมีหลายส่วนได้

ตัวอย่างสำหรับ- “แนวคิดไปป์” ใน “ประโยค PowerShell” อาจเป็น:

คำสั่ง "รับ"

PowerShell cmdlet ที่ขึ้นต้นด้วยคำนำหน้า "รับ " เป็นพิเศษเนื่องจากเราสามารถใช้เพื่อวัตถุประสงค์สองประการ:

1. รับวัตถุและแสดงข้อมูลเกี่ยวกับวัตถุ

ตามค่าเริ่มต้น เมื่อเราใช้ Get cmdlets เป็นคำสั่ง “แบบสแตนด์อโลน” คำสั่ง Get จะรับ/ดึงวัตถุ + แสดงข้อมูลเกี่ยวกับวัตถุ

เราสามารถใช้เอาต์พุต (ข้อมูลเกี่ยวกับวัตถุ) จากคำสั่ง Get ได้สองวิธี:

• แสดงบนหน้าจอ - ตามค่าเริ่มต้น เมื่อใช้คำสั่ง Get ข้อมูลเกี่ยวกับออบเจ็กต์จะแสดงบนหน้าจอ (คอนโซล PowerShell)

• ส่งออกข้อมูลไปยังไฟล์ - ตัวเลือกที่สองที่เรามีคือ: ส่งออกข้อมูลไปยังไฟล์ ข้อมูลนี้สามารถใช้เพื่อวัตถุประสงค์สองประการ:

  • รายงาน: เราสามารถใช้ข้อมูลจากคำสั่ง Get เพื่อสร้างรายงานเกี่ยวกับโครงสร้างพื้นฐาน เช่น จำนวนผู้ใช้ ใบอนุญาตที่ผู้ใช้แต่ละรายมี ข้อมูลเกี่ยวกับกล่องจดหมาย เป็นต้น
  • แก้ไขข้อมูลอีกครั้ง: เราใช้ตัวเลือก "แก้ไขข้อมูล" โดยใช้ยูทิลิตี้เพิ่มเติม (นอกเหนือจาก PowerShell) เพื่อแก้ไขหรือ "จัดการ" ข้อมูล

<แข็งแกร่ง>2. รับและไปป์ไลน์

การใช้งานครั้งที่สองสำหรับ Get cmdlets คือการใช้ get cmdlets เป็นส่วนแรกของประโยค PowerShell ที่ทำหน้าที่เป็น "พื้นฐาน" สำหรับส่วนอื่นๆ ของประโยค PowerShell

ในบทความถัดไป เราจะเริ่มต้นใช้งาน Office 365 PowerShell | เล่นกับ Get-mailbox บนหน้าจอแสดงผล | ตอนที่ 2#4.