तीसरी पॉवरशेल से मिलो (भाग I)

आधुनिक प्रौद्योगिकियों के विकास की गति ऐसी है कि हम मुश्किल से उनके साथ रह सकते हैं। लेकिन आज हम थोड़ा आगे चलेंगे, हम PowerShell v3 के नवाचारों के बारे में जानेंगे और हम न केवल अपनी आँखों से, बल्कि अपने हाथों से भी उनकी जाँच करेंगे।

बूथ

मैंने हाइपर-वी के तहत विंडोज सर्वर 2012 आरसी पर आधारित दो मशीनों को इकट्ठा किया, litware.inc नामक एक डोमेन से एक जंगल बनाया। डोमेन में दो मशीनों को क्रमशः w2012dc1.litware.inc और w2012cl1.litware.inc कहा जाता है। w2012dc1 डोमेन सेवाएं और DNS कताई कर रहे हैं, और w2012cl1 पर कुछ भी नहीं w2012cl1 रहा है, वास्तव में, केवल ओएस। डोमेन में भी उपयोगकर्ता user1 , जो domain users समूह का सदस्य है। बेशक, दूसरी मशीन पर विंडोज 8 आरसी स्थापित करना संभव था, इसलिए बोलने के लिए, सौंदर्य के लिए, लेकिन मैंने दो स्वतंत्र वर्चुअल हार्ड ड्राइव का उपयोग करने के बजाय एक माता-पिता आभासी हार्ड ड्राइव और दो बच्चों को हुक करके थोड़ा डिस्क स्थान बचाने का फैसला किया।
इसके अलावा, मुझे यह उल्लेख करना चाहिए कि मेरे द्वारा उपयोग की जाने वाली सभी शर्तें पहले से ही स्थानीयकृत हैं और Microsoft भाषा पोर्टल पर उपलब्ध हैं, इसलिए मैं इन अनुवादों को ठीक वैसे ही देता हूं जैसा कि मैं इन शर्तों को समझता हूं, और कोष्ठक में मैं मूल नाम अंग्रेजी में देता हूं।

नई सुविधाएँ

सबसे पहले, आइए उन्हें सूचीबद्ध करें, यह:

• वर्कफ़्लोज़ (संलग्न। वर्कफ़्लोज़ ) कुछ प्रक्रियाएँ होती हैं जो क्रमिक रूप से या समानांतर में चलती हैं, जटिल प्रबंधन कार्य करती हैं। वास्तव में, PowerShell v3 में अब Windows वर्कफ़्लो फ़ाउंडेशन के लिए समर्थन शामिल है, और PowerShell वर्कफ़्लोज़ स्वयं दोहराए जाने योग्य, समानांतर, बाधित और पुनर्प्राप्त करने योग्य हैं।
• विश्वसनीय सत्र ( रोबस्ट सेशन ) पॉवरशेल सत्र हैं जो नेटवर्क मुसीबतों और समान रुकावटों के बाद स्वचालित रूप से बहाल हो जाते हैं। यह तकनीक आपको एक मशीन पर एक सत्र से डिस्कनेक्ट करने और दूसरे पर उसी सत्र से कनेक्ट करने की अनुमति देती है।
• शेड्यूल्ड जॉब्स पॉवरशेल जॉब्स हैं जो एक विशिष्ट अंतराल पर, या किसी घटना के जवाब में चल सकते हैं।
• सत्र के लिए विशेष कॉन्फ़िगरेशन (Eng। कस्टम सत्र कॉन्फ़िगरेशन ) - प्रत्येक PowerShell सत्र के लिए, आप मापदंडों के एक विशेष सेट को पूर्वनिर्धारित कर सकते हैं और उन्हें एक विशेष कॉन्फ़िगरेशन फ़ाइल में सहेज सकते हैं, ताकि आप बाद में सत्र में प्रवेश कर सकें।
• सरलीकृत भाषा वाक्य रचना - कथित रूप से, एक सरल वाक्यविन्यास एक PowerShell स्क्रिप्ट को प्रोग्राम की तरह कम और प्राकृतिक मानव भाषा की तरह अधिक देखने की अनुमति देता है।
• Cmdlet की खोज ( Cmdlet की खोज ) - मॉड्यूल का स्वचालित लोडिंग जिसमें cmdlet स्थित है, यदि यह मॉड्यूल है, तो निश्चित रूप से मशीन पर स्थापित है।
• शो-कमांड केवल नए cmdlets में से एक है जिसे हम शायद शुरू करेंगे।

कमांड दिखाओ

इसके लॉन्च के बाद, मापदंडों के बिना, एक खिड़की दिखाई देती है, जिसमें से यह भव्यता और ठाठ के साथ उड़ती है:
यदि पहले आपको TechNet पर किसी विशेष cmdlet की खोज करनी थी, या यहाँ तक कि .NET ऑब्जेक्ट्स का उपयोग करना था, तो यहाँ आप हैं, मुझे सभी मॉड्यूल नहीं चाहिए, सभी cmdlets, देखें -



ठीक है, यदि आप कृपया, DNS सर्वर और DNS क्लाइंट सेवा के प्रबंधन के लिए cmdlets, और यदि आप एक मॉड्यूल का चयन करते हैं, उदाहरण के लिए, एक नेटवर्क मॉड्यूल, तो आप रूटिंग टेबल को कॉन्फ़िगर करने के लिए cmdlets का पता लगा सकते हैं या, उदाहरण के लिए, नेटवर्क इंटरफेस के टीसीपी / आईपी पैरामीटर।



इसके अलावा, मैंने "शेयर", "उपयोगकर्ता", "एसीएल", "नीति", "एडेप्टर" और इतने पर और इसके बाद के शब्दों को खोजने की कोशिश की, यह दिलचस्प है।

Cmdlet की खोज

पिछले एक के साथ संबद्ध, लेकिन सीधे निर्भर नहीं। Windows Server 2008 R2 में PowerShell v2 में, कुछ कार्यों को करने के लिए, आपको एक या किसी अन्य मॉड्यूल को कनेक्ट करने की आवश्यकता होती है, PowerShell v3 स्वचालित रूप से यह निर्धारित करता है कि cmdlet चलाने के लिए कौन सा मॉड्यूल जिम्मेदार है और पृष्ठभूमि में यह मॉड्यूल बिना किसी प्रश्न के लोड होता है।
तुलनीय। यदि मैंने उन्हें PowerShell v2 में डाउनलोड करने का प्रयास किया तो मैंने डोमेन समूह नीतियों की एक सूची प्राप्त करने का निर्णय लिया:

 Get-GPO -All | ft Id #     Id ,   

तब हमें एक त्रुटि मिलती है, क्योंकि GroupPolicy मॉड्यूल लोड नहीं है:

 Import-Module GroupPolicy 

अब, यदि आप दोहराते हैं, तो सब कुछ ठीक हो जाता है:



PowerShell v3 में, सब कुछ शुरुआत से ठीक है:

सरलीकृत भाषा वाक्य रचना

यहाँ, यह मुझे प्रतीत हुआ, डेवलपर्स ने भाषा को SQL के करीब लाने का फैसला किया, ठीक है, कम से कम एक निश्चित सादृश्य है। तथ्य यह है कि उन्होंने Foreach-Object और Foreach-Object सेमीडलेट्स के लिए नए वाक्यविन्यास पेश किए। यद्यपि Foreach का व्यावहारिक मूल्य:

 Get-Service | Foreach Name 

के बजाय

 Get-Service | Foreach {$_.Name} 

मेरी राय में, संदिग्ध।
एक और बात Where :

 Get-Service | Where Status -eq Running 

के बजाय

 Get-Service | Where {$_.Status -eq "Running"} 

पहले से ही कुछ भी नहीं, बिना किसी ब्रेसिज़ के साथ डॉलर के उद्धरण के साथ।
कुछ नए ऑपरेटरों को भी दिखाई दिया है: -NotIn और -NotIn , एक सीमा को दर्शाता है। उनके साथ, मुझे लगता है, समझ से अधिक:

कस्टम सत्र कॉन्फ़िगरेशन

सबसे उल्लेखनीय नवाचार जो मैं पहले भाग के बारे में बात करना चाहता हूं वह प्रशासनिक प्राधिकरण के प्रतिनिधिमंडल के साथ संयोजन में सत्र का कॉन्फ़िगरेशन है। कॉन्फ़िगरेशन फ़ाइल अपने आप में .pssc एक्सटेंशन वाली फाइल होती है, जिसमें सिर्फ प्रॉपर्टीज और वैल्यूज़ की हैश टेबल होती है: ऑथरशिप, लैंग्वेज, वेरिएबल्स, फंक्शन्स डेफिनिशन आदि। सत्र कॉन्फ़िगरेशन में ही, अन्य गुण भी हैं:

 Get-PSSessionConfiguration | Get-Member 

इसके समान एक तस्वीर दिखाई देगी:



देखें कि कितने कस्टम विकल्प हैं? आप उस चित्र से भी तुलना कर सकते हैं जो PowerShell v2 में इस कमांड को चलाने पर दिखाई देता है और अंतर महसूस करता है।
लेकिन इसका उपयोग कैसे करें? और अब मैं दिखाऊंगा, मुझे स्वीकार करना चाहिए, मैं इन लाइनों को लिखने के लिए इसे लंबे समय से उठा रहा हूं। इसलिए, हम क्रमिक रूप से निष्पादित करते हैं:

 $defSSDL = (Get-Item WSMan:\localhost\Service\RootSDDL).Value # SSDL " " $SecDescriptor = New-Object -TypeName Security.AccessControl.CommonSecurityDescriptor $false, $false, $defSSDL #   $user = Get-ADUser "user1" #  Active Directory  ,  , ,    $SecDescriptor.DiscretionaryAcl.AddAccess([System.Security.AccessControl.AccessControlType]::Allow, $user.SID.Value, 268435456, [System.Security.AccessControl.InheritanceFlags]::None, [System.Security.AccessControl.PropagationFlags]::None) # SID   $sddl = $SecDescriptor.GetSddlForm("All") # ,   $creds = Get-Credential "administrator@litware.inc" #    New-PSSessionConfigurationFile -Path .\DnsRead.pssc -SessionType RestrictedRemoteServer -VisibleCmdlets "Show-DnsServer*" -ModulesToImport DnsServer #   Register-PSSessionConfiguration -Name DnsRead -Path .\DnsRead.pssc -AccessMode Remote -SecurityDescriptorSddl $sddl -RunAsCredential $creds #  

ध्यान दें कि मैंने कॉन्फ़िगरेशन को केवल DnsServer मॉड्यूल तक सीमित कर दिया है और केवल Show-DnsServer पर शुरू होने वाले cmdlets के लिए, यह सुनिश्चित करता है कि शेल स्वयं administrator@litware.inc w2012cl1 विशेषाधिकारों के साथ चलाया जाएगा, दूरस्थ उपयोगकर्ता user1 दूरस्थ मशीन w2012cl1 से कुछ भी करने में सक्षम नहीं होगा। शायद इसे छोड़कर:



एक आसान बात है, है ना? PowerShell के अंदर मॉड्यूल और cmdlets को प्रतिबंधित करके, हम आसानी से और बिना शर्त कुछ कर्मचारियों को DNS और दूसरों के लिए जिम्मेदार बना सकते हैं जो नेटवर्क के लिए हमारी प्रशासकों की टीम के अंदर हैं, और उदाहरण के लिए, उपयोगकर्ताओं को एकदिवसीय वीडीआई के अंदर अपनी हाइपर-वी मशीनों को स्नैपशॉट देने का अधिकार है, और कोई भी नहीं करेगा उस उपयोगकर्ता के क्रेडेंशियल्स को जानें जिसके तहत कार्य किया जाता है! और समाप्त कॉन्फ़िगरेशन फ़ाइल को समान कार्यों के साथ बस एक स्थान से अन्य सभी सर्वरों में स्थानांतरित किया जाता है।
अगले भाग में, हम आगे बढ़ेंगे, या सूची के बजाय, हम विश्वसनीय सत्रों, निर्धारित कार्यों और निश्चित रूप से, कार्य प्रक्रियाओं का विश्लेषण करेंगे। खैर, और शायद नए पॉवरशेल आईएसई पर थोड़ा सा स्पर्श, वहाँ भी कुछ देखना है।