PowerShell स्क्रिप्ट में व्यवस्थापक के रूप में कमांड चलाएं। यूएसी

ठीक है मेरी समस्या है:PowerShell स्क्रिप्ट में व्यवस्थापक के रूप में कमांड चलाएं। यूएसी

मैं एक सर्वर पर दूरस्थ रूप से एक स्क्रिप्ट चलाने की कोशिश कर रहा हूं।

मैं दोनों बॉक्सों पर एक व्यवस्थापक हूं, फ़ायरवॉल अपवाद हैं, दूरस्थ व्यवस्थापक सक्षम है, और बाकी सब कुछ अच्छा दिखता है जो मैं देख सकता हूं।

invoke-command -ComputerName $ComputerName -ScriptBlock ` 
{ 
    cd C:\Windows\System32\inetsrv\; 
    ./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files> 
}

मैं आर 2 बॉक्स 2k8 एक सर्वर है वापसी

ERROR (hresult:80070005, message:Failed to commit configuration changes. Access is denied.

सर्वर उस पर चलाने के लिए कोशिश कर रहा है में निम्न त्रुटि प्राप्त हो रही है और मैं सोच रहा हूँ इस मुद्दे को एक यूएसी समस्या है। क्या यूएसी बॉक्स पर हाँ पर क्लिक किए बिना व्यवस्थापक के रूप में चलाने के लिए वैसे भी है?

कोड का यह टुकड़ा अंततः एक स्क्रिप्ट बन जाएगा जो पूरी तरह से स्वचालित होना होगा।

किसी भी मदद की सराहना की जाएगी।

स्रोत

2010-02-11 Tim

ठीक है यह यूएसी नहीं है। मैंने यूएसी, फ़ायरवॉल को अक्षम कर दिया, और बाकी सब कुछ मैं सोच सकता था कि हस्तक्षेप होगा। मैंने टायरिनिड द्वारा सुझाए गए रजिस्ट्री परिवर्तन को भी बनाया है। न तो काम करता है। यह अजीब है। यह कहता है कि ऑपरेशन सफल रहा था, फिर उसी पहुंच को अस्वीकार कर दिया गया है। – Tim

क्या आप दूरस्थ शक्तिशक्ति उदाहरण पर 'व्हामी/सब' चला सकते हैं और देख सकते हैं कि वास्तव में आपके पास क्या अनुमतियां हैं? – tyranid

मैंने आदेश चलाया और यह मेरे डोमेन खाते का नाम सूचीबद्ध किया, समूह मैं डोमेन पर सदस्य हूं, और विशेषाधिकारों की एक सूची। सभी विशेषाधिकार प्रशासक स्तर और सक्षम थे, सूचीबद्ध समूहों में से एक प्रशासक समूह में है और सभी सही दिखते हैं। – Tim

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

मैंने जोड़ा- क्रेडेंशियल इनवॉक कमांड पर स्विच करें और सबकुछ अब बढ़िया काम कर रहा है। नीचे सही कोड नमूना:

$user = New-Object Management.Automation.PSCredential("$UserName", $securePassword) 
invoke-command -ComputerName $ComputerName -Credential $user -ScriptBlock ` 
{ 
    cd C:\Windows\System32\inetsrv\; 
    ./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files> 
}

स्रोत

2010-02-13 15:53:15 Tim

तो जब किसी चीज को स्क्रिप्ट करते हैं जिसके लिए व्यवस्थापक अधिकारों की आवश्यकता होती है, तो स्क्रिप्ट में cleartext में उपयोगकर्ता नाम और पासवर्ड रखने से बेहतर तरीका नहीं है? वास्तव में? व्यवस्थापक के रूप में सेवा चलाने के लिए पर्याप्त नहीं है ... स्क्रिप्ट के लिए सबसे अच्छा अभ्यास क्या है, कहें, एक विंडोज़ सेवा स्थापना जिसके लिए व्यवस्थापकीय अधिकारों की आवश्यकता है? –

विकल्प उपयोगकर्ता को गेट-क्रेडेंशियल cmdlet के माध्यम से प्रमाण-पत्र दर्ज करने देना है। – riezebosch

-3

क्या यूएसी बॉक्स पर हाँ पर क्लिक किए बिना व्यवस्थापक के रूप में चलाने के लिए इसे प्राप्त करने के लिए वैसे भी है?

यदि यह संभव था तो यह पूरी तरह से यूएसी के बिंदु को पराजित करेगा।

इस प्रकार, यह बॉक्स पर यूएसी को अक्षम करने का आपका एकमात्र वास्तविक समाधान दिखाई देगा।

स्रोत

2010-02-11 22:06:52

दुर्भाग्यवश यूएसी को अक्षम करना एक विकल्प नहीं है क्योंकि यह उच्च दृश्यता सर्वर पर होगा। उम्मीद है कि कोई समाधान या समाधान का पता लगा सकता है। शायद मैं कुछ गलत कर रहा हूँ। – Tim

दूसरा विकल्प यह होगा कि जो कुछ भी इन स्क्रिप्ट्स को ऊपर उठाएगा, तब यह अन्य ऊंचा प्रक्रियाओं को बिना किसी यूएसी पुष्टिकरण की आवश्यकता के उत्पन्न कर सकता है। –

मेरे साथ एकमात्र प्रश्न यह है कि यह दूरस्थ रूप से आगे बढ़ेगा। यह स्क्रिप्ट प्रबंधन सर्वर से एकाधिक सर्वर पर विभिन्न आदेश चलाएगी। तो सर्वर ए (mgmt) सर्वर 1, 2, और 3 पर दूरस्थ रूप से आदेश चलाता है। यदि प्रक्रिया सर्वर ए पर उन्नत के रूप में चल रही है, तो यह सर्वर 1, 2, और 3 पर ऊंचा चलने वाला है? – Tim

This इंगित करता है कि आपको यह सुनिश्चित करने की आवश्यकता है कि आप रिमोट मशीन पर स्थानीय व्यवस्थापक हैं (हालांकि स्वीकार्य रूप से यह विशेष रूप से डब्लूएमआई के लिए है)। this के अनुसार आप प्रशासक के लिए रिमोट लॉगऑन पर लागू यूएसी को रोकने के लिए रजिस्ट्री कुंजी बदल सकते हैं (LocalAccountTokenFilterPolicy के लिए खोजें)। यदि आप व्यवस्थापक खाते के साथ दूरस्थ रूप से पावरहेल/डब्ल्यूएमआई का उपयोग करते हैं तो यूके को निष्क्रिय नहीं करना चाहिए।

स्रोत

2010-02-11 22:24:15 tyranid

-3

सेट विकल्प "EnableLUA" (DWORD मान) HKLM \ SOFTWARE \ Microsoft \ Windows में पाया \ CurrentVersion \ Policies \ प्रणाली 0 और रिबूट करने के लिए।

यह बिना किसी समस्या के यूएसी को अक्षम कर देगा, मैं आपके सभी उपयोगकर्ताओं के लिए ऐसा करूँगा, चाहे अनुमति के साथ या बिना आपके पास है, क्योंकि विस्टा यूएसी इतना डरावना है कि मुझे विश्वास है कि कम लोग जिनके पास यह है बेहतर (कम से कम विस्टा में) वे हैं। Thsi चाल भी Win7 में भी काम करता है। (एक मेहनती जवाब था यह इतना पता चला है के रूप में टिप्पणी यूएसी निष्क्रिय करने के लिए कैसे जहाँ तक ऊपर जवाब के साथ अपनी पोस्ट/धागा संबंध है पता चलता है कि रोक लगाए है:

मेरी रजिस्ट्री चाल :)

पी एस के साथ मज़े हटा दिया)।

स्रोत

2010-07-29 15:09:54

मुझे नहीं लगता कि वे आपको जिस तरह से समझ रहे हैं, उन्हें सेंसर कर रहे हैं। मेरा सबसे अच्छा अनुमान है कि आपने कुछ ऐसी सिफारिश की है जो एक आरामदायक उपयोगकर्ता के लिए सुरक्षा जोखिम प्रदान कर सके। यूएसी किसी कारण से है कि क्या यह सफलतापूर्वक हासिल किया गया है या नहीं, इस प्रश्न के दायरे से बाहर है;) – Kounavi

@ कौनावी अच्छी तरह से हाँ, आप सही हैं, यह इस प्रश्न के दायरे से बाहर है, इसलिए मैंने सवाल का जवाब दिया और शामिल किया एक साइड टिप्पणी के रूप में मेरी दूसरी टिप्पणी। अगर इस तरह के भयंकर तरीके से कुछ किया जाता है, तो देवताओं को एक सबक सिखाने के लिए इसका विरोध और अक्षम किया जाना चाहिए, और इससे भी महत्वपूर्ण बात यह है कि इस वजह से आप जिस सुरक्षा को प्रदान करते हैं, उससे कहीं अधिक आपदाएं इससे अधिक होती हैं, यह विस्टा के मुख्य कारणों में से एक था एक विशाल आपदा थी। –

PowerShell स्क्रिप्ट में व्यवस्थापक के रूप में कमांड चलाएं। यूएसी

उत्तर

संबंधित मुद्दे