सवाल मौजूदा एक्सचेंज 2003 वातावरण को उपयोगकर्ताओं के लिए "केवल पढ़ने" बनाना


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

एक बार नई प्रणाली उत्पादन हो जाने के बाद, हम विरासत वातावरण तक उपयोगकर्ता पहुंच को सुविधाजनक बनाना चाहते हैं। यह ई-मेल में मौजूद जानकारी की निरंतरता की अनुमति देगा (ई। जी। दिन एक नई प्रणाली पर, उपयोगकर्ता पुराने सिस्टम में दिखाई देने वाले संदेश के जवाब के रूप में एक नया संदेश भेज सकते हैं)। हम इसे केवल पढ़ने के लिए फैशन में करना चाहते हैं, यह सुनिश्चित करने के लिए कि विरासत पर्यावरण में उपयोगकर्ता कार्यों के परिणामस्वरूप कोई परिवर्तन नहीं हो रहा है। (पुराने पर्यावरण का यह "लॉक" कानूनी विभाग से ई-खोज चिंताओं से संबंधित है।)

इस प्रश्न के प्रयोजनों के लिए, ब्याज की विरासत पर्यावरण एक एक्सचेंज 2003 पर्यावरण है, जिसमें Outlook और OWA पहुंच उपलब्ध है। उपयोगकर्ताओं के पास आउटलुक 2003 प्रोफाइल आज है जो विरासत पर्यावरण के खिलाफ काम करता है।

हमने कुछ हैक उत्तरों के बारे में सोचा है - जैसे परिवर्तनों को रोकने के लिए प्रत्येक उपयोगकर्ता मेल फ़ोल्डर पर बदलती अनुमतियों को स्क्रिप्टिंग करना - लेकिन ऐसा नहीं लगता कि इस समस्या का "अच्छा" जवाब है। विशेष रूप से, हम किसी की अपनी जानकारी (ई जी। ई-मेल हटाने) को बदलने के बारे में चिंतित हैं, और इंट्रार्गनाइजेशन ई-मेल (संगठन में किसी अन्य उपयोगकर्ता को एक्सचेंज संगठन ई-मेल में ई-मेल के बारे में चिंतित होने के बावजूद)।

इस समय पर्यावरण लगभग 15 टीबी है, इसलिए पीएसटी को सबकुछ निर्यात करने और उपयोगकर्ताओं तक पहुंच प्रदान करने का विचार पर चर्चा की गई लेकिन इसे असुरक्षित के रूप में छोड़ दिया गया।

क्या ऐसा करने का कोई "अच्छा" तरीका है जिसे हमने नहीं सोचा है? मुझे पता है कि बुनियादी अंतर्निहित प्रश्न पूछने के समान है, "हम इस मेल सिस्टम को किसी भी मेल यातायात से कैसे रोक सकते हैं?" मैं यह नहीं कह रहा कि यह एक उचित अनुरोध है। मैं सिर्फ यह समझने के लिए उचित परिश्रम कर रहा हूं कि यह एक सौहार्दपूर्ण तरीके से संभव है या नहीं।

धन्यवाद!

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

p.p.s. विरासत प्रणालियों में नोट्स भी शामिल हैं, इसलिए मैं स्रोत के रूप में नोट्स के साथ एक ही प्रश्न पूछने जा रहा हूं। उन दोनों को एक प्रश्न में बनाने का अधिकार नहीं था।

संपादित करें: बस 100% होने के लिए, भेजने / प्राप्त करने से रोकना इसका हिस्सा है, लेकिन मौजूदा डेटा की अखंडता को बनाए रखना भी ई है। जी। मौजूदा आइटम को हटाने से रोकें।

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

संपादित करें 3: ठीक है, इसलिए मैंने अभी अपने मालिक से बात की और एक दिलचस्प विचार आया। यदि हम उत्तर में से किसी एक में नीचे चर्चा करते हैं और प्रीनापशॉट लेते हैं, तो सभी मेल प्रवाह को रोकें, हमें हटाए जाने की परवाह नहीं है, क्योंकि स्नैपशॉट में मूल्य के सब कुछ है। टूटा मेल प्रवाह की वजह से कुछ खोजने योग्य "जोड़ने" का कोई तरीका नहीं है। तो शायद यह काफी करीब है। अगर हम एमटीए सेवा को अक्षम करते हैं, तो क्या यह इंट्राडाबेस मेल प्रवाह को रोक देगा? क्या यह अभी भी डेटा पहुंच की अनुमति देते हुए "ज्ञात अच्छी" खोज स्थिति प्राप्त करने के लिए हमले की उचित योजना है?


5
2017-08-24 18:50


मूल




जवाब:


जो भी आप खोज रहे हैं उसे करने के लिए कोई "सौदा" तरीका नहीं है। उपयोगकर्ताओं को वस्तुओं को हटाने / संशोधित करने में सक्षम होने से रोकने के लिए आपको सभी मेलबॉक्स पर अनुमतियां बदलने की आवश्यकता होगी।

मुझे लगता है कि, एक ईडिसवरी परिप्रेक्ष्य से, आप वर्तमान प्रणाली का बैक अप लेने और इसे कुछ आभासी मशीनों पर "ग्लास के नीचे" बहाल करने में एक सस्ता और अधिक भरोसेमंद समाधान के साथ समाप्त हो जाएंगे। जब तक कोई खोज अनुरोध नहीं आया तब तक आप वीएम को ऑफ़लाइन रख सकते थे। अगर ऐसा होता है, तो आप उचित गति से खोज को सुविधाजनक बनाने के लिए आवश्यक हार्डवेयर पर उन्हें स्पिन कर सकते हैं। मैं मेलबॉक्स डेटाबेस को कई छोटे "भाग" (प्रत्येक टीबी के प्रत्येक कहते हैं) में तोड़ दूंगा ताकि आप सभी 15TB लाने के लिए ऑनलाइन eDiscovery वातावरण का एक हिस्सा ला सकें।

इससे आपको वर्तमान विरासत एक्सचेंज पर्यावरण के साथ छोड़ दिया जाता है, जो उपयोगकर्ता "जंगली दौड़ सकते हैं"। उपयोगकर्ताओं को संशोधनों को रोकने से रोकने के लिए आपको इसमें कोई बदलाव नहीं करना पड़ता है।

यदि आपको विरासत पर्यावरण में किसी भी मेलबॉक्स सर्वर के बीच किसी भी मेल प्रवाह की आवश्यकता नहीं है तो आप मशीनों पर केवल SMTP सेवाओं को रोक सकते हैं। इससे मेल प्रवाह मर जाएगा।

संपादित करें:

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

आप प्रत्येक मेलबॉक्स स्टोर पर एक जर्नल प्राप्तकर्ता को कॉन्फ़िगर कर सकते हैं जैसे "विरासत सहअस्तित्व" अवधि के दौरान इंट्रा-संगठन भेजे गए किसी भी नए संदेश को जर्नल किया जाएगा। यह अभी भी उपयोगकर्ताओं को उनके मेलबॉक्स में पहले से मौजूद वस्तुओं को संशोधित करने में सक्षम होने में सहायता नहीं करेगा।

2 संपादित करें (@ माइकबज़ संपादित 3 का जवाब देना):

दुर्भाग्यवश, एमटीए सेवा को रोकना, सूचना स्टोर के भीतर ईमेल वितरण को रोक नहीं पाएगा। एक बेहतर विचार सभी प्राप्तकर्ताओं को किसी भी अन्य वैध प्राप्तकर्ताओं से ईमेल प्राप्त करने से रोकने के लिए होगा। आप इसे सेट करके कर सकते हैं authOrig प्रत्येक ऑब्जेक्ट की विशेषता किसी ऑब्जेक्ट के डीएन को करें (एक "संपर्क" ऑब्जेक्ट को एक मेक-अप ईमेल पता के साथ कहें) जो उन्हें ईमेल कभी नहीं भेजेगा। यह प्रत्येक प्राप्तकर्ता को किसी अन्य प्राप्तकर्ता से ईमेल प्राप्त करने में सक्षम होने से रोक देगा (इस फर्जी "संपर्क" ऑब्जेक्ट को छोड़कर)।

ऐसा करने और किसी भी आउटबाउंड एसएमटीपी को विरासत संगठन (एसएमटीपी वर्चुअल सर्वर को रोककर या उन्हें फ़ायरवॉल करके) से बहने से रोकने के बीच आप एक पूरी तरह से अलग विरासत संगठन के साथ समाप्त हो जाएंगे।


2
2017-08-24 19:14



आह, लेकिन जंगली चलने का एक छिपी जोखिम है - जैसे ही विरासत में उपयोगकर्ता किसी अन्य उपयोगकर्ता को विरासत में एक ई-मेल भेजता है, अब आपके पास एक डेटा आइटम है जो संभावित रूप से भविष्य की खोज परिदृश्य में आवश्यक है। मुझे पता है कि यह बेवकूफ है - उपयोग नीति मदद कर सकती है ताकि कम से कम आप कह सकें "हमने उन्हें नहीं बताया, आपका सम्मान" - लेकिन मैं यह बता रहा हूं कि मुझे क्या बताया गया है और यह सुनिश्चित करने की कोशिश कर रहा है कि कुछ याद नहीं है तकनीकी पक्ष जो हमें बाद में जला देगा। - MikeBaz - MSFT
@ माइकबाज़: यह एक अच्छा मुद्दा है। आप प्रत्येक उपयोगकर्ता पर डिलीवरी अनुमतियों को किसी भी अन्य प्राप्तकर्ता को डिलीवरी संदेशों की क्षमता से इनकार करने की अनुमति देने के लिए बदल सकते हैं, लेकिन फिर भी उन्हें "प्रेषित आइटम" या अन्यथा उनके विरासत मेलबॉक्स में गिलहरी-दूर डेटा बनाने की अनुमति मिलती है। सभी मेलबॉक्सों पर बदलती अनुमतियां शायद आपका एकमात्र समाधान है। आप शायद लागत बिंदु पर तेजी से आ रहे हैं, हालांकि, जहां बस पीएसटी को सबकुछ निर्यात करना संभव होगा। - Evan Anderson
यह काफी अच्छी तरह से मेल खाता है जहां मेरी सोच इस बिंदु पर है। ऐसा लगता है कि अब तक जवाब और टिप्पणियां पढ़ने से यह अंतिम बिंदु है। मैं यह सुनिश्चित करने के लिए कि कुछ भी जादू बुलेट के साथ आता है, लेकिन मुझे नहीं लगता कि यह जवाब होने जा रहा है, लेकिन मैं कुछ दिनों के लिए सवाल चलाने जा रहा हूं। - MikeBaz - MSFT
@ माइकबज़: मैंने एक संपादन डब्ल्यू / कुछ मामूली वस्तुओं पर गिरा दिया। - Evan Anderson
@ माइकबज़: मैंने आपके "संपादन 3" का जवाब देने के लिए एक और संपादन पर गिरा दिया। - Evan Anderson


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

एक्सचेंज 2003 आपको मेलबॉक्स सीमाएं सेट करने की अनुमति देता है जिसका उपयोग आप नए मेल को भेजने और प्राप्त करने से रोकने के लिए भी कर सकते हैं, लेकिन यह मौजूदा मेल को हटाने से नहीं रोकेगा।

संपादित करें (क्योंकि मेरी टिप्पणी लंबी हवादार हो गई है): आपको प्रबंधन / कानूनी मार्गदर्शन के साथ अपनी जरूरतों को प्राथमिकता देना चाहिए। यदि ई-डिस्कवरी प्राथमिक चिंता है, और एक पूर्ण आवश्यकता है, तो एकमात्र तरीका है कि आप ई-डिस्कवरी उद्देश्यों के लिए एक स्थिर प्रणाली की गारंटी देने में सक्षम होने जा रहे हैं जो कानूनी अर्थ में कायम रहेगा विरासत का पूर्ण बैकअप लेना सिस्टम और इसे ऑफ़लाइन रखें। डेटा संशोधन को रोकने के लिए विभिन्न "तकनीकी" उपायों को जोड़ना केवल स्थिति की जटिलता को जोड़ देगा और संभवतः कानूनी रूप से ध्वनि समाधान नहीं होगा। कभी भी बैकअप ऑनलाइन कभी नहीं लाओ। यदि आपको अपने पुराने ई-मेल से गड़बड़ करने वाले किसी भी व्यक्ति के लिए बाद में देखने के लिए बैकअप की आवश्यकता है, तो 2 बैकअप लें, लेकिन हमेशा उनमें से 1 को 100% ऑफ़लाइन रखें और लॉक हो जाएं, केवल दस्तावेज़ों तक पहुंचने वाले बहुत कम लोगों तक उपलब्ध हों एक सबपोना या कुछ अन्य कानूनी कारणों से ई-मेल बैकअप की आवश्यकता होती है। बैकअप एन्क्रिप्ट करना भी एक अच्छा विचार है।

यदि ई-डिस्कवरी "अच्छा होगा", लेकिन केवल पढ़ने के लिए "सक्रिय" विरासत प्रणाली अधिक महत्वपूर्ण है, तो मैं केवल सभी के लिए पीएसटी की सिफारिश कर सकता हूं और विरासत प्रणाली को बंद कर सकता हूं। जितना अधिक पीआईटीए उन्हें बनाना होगा, मुझे अभी भी लगता है कि आपके मौजूदा सिस्टम को लॉक-डाउन करने और इसे चालू रखने की कोशिश करने से कहीं अधिक आसान है। अगर किसी चीज को हटाने का कोई प्रश्न है तो आप तुलना करने के लिए डुप्लिकेट पीएसटी रख सकते हैं और यह विघटन होने के बाद से मेल भेजने के लिए विरासत प्रणाली का उपयोग करना संभव नहीं होगा। यदि आप कभी निर्णय लेते हैं तो आप इसे नए सिस्टम में भी आयात कर सकते हैं। मुझे एहसास है कि 30 टीबी डेटा पकड़ने के लिए है, लेकिन यह वह डेटा है जो आप डेटा उपलब्धता और nonrepudiation के लिए भुगतान करते हैं ...


2
2017-08-24 19:14



नई प्रणाली लाइव होने से पहले योजना वास्तव में एक स्नैपशॉट बैकअप लेना है, लेकिन अगर हम सिस्टम को केवल पढ़ने के लिए चिह्नित नहीं कर सकते हैं (हटाएं, भेजें / प्राप्त करें उसी सिक्का के फ्लिप पक्ष हैं) तो हमें बनाए रखना जारी रखना होगा बैकअप, आदि उपलब्धता उपलब्धता खिड़की में कोई परिवर्तन / हानि प्रदर्शित करने में सक्षम होने के लिए या किसकी कलाई को थप्पड़ मारने में सक्षम होना चाहिए। - MikeBaz - MSFT
दुर्भाग्य से उपयोगकर्ताओं के लिए कम से कम इस समय खोज पहलू प्राथमिकता लेता है। एक निश्चित बिंदु है, जहां उपयोगकर्ताओं को वास्तव में अपनी नौकरियां, खोज या नहीं करने में सक्षम होना चाहिए, इसलिए मुझे लगता है कि हम स्वीकार्य जोखिम के सवाल पर आ रहे हैं, जो निश्चित रूप से एक एसएफ सवाल नहीं है बल्कि ग्राहक निर्णय बिंदु है। - MikeBaz - MSFT


यह थोड़ी देर के बाद से मैंने एक्सचेंज 2003 का उपयोग किया है, लेकिन मुझे याद है कि आप एक्सब्सक्रिप्शन में vbscripts डाल सकते हैं। क्या आप सभी मेलबॉक्स पर एक स्क्रिप्ट डाल सकते हैं जो ईमेल भेजने से रोक देगा?


1
2017-08-24 19:01



मेल प्रवाह को रोकने के लिए आप 0kb पर ईमेल आकार सीमा भेज / प्राप्त कर सकते हैं। - HostBits
ठीक है, यह एक दिलचस्प विचार है। क्या आप अनिवार्य रूप से एक एक्सचेंज इवेंट सिंक के बारे में सोच रहे हैं? मुझे हमेशा विश्वास था कि घटना सिंक के संबंध में, ड्रैगन होंगे, लेकिन यह एक दिलचस्प विचार है। मैं और अधिक शोध कर सकता हूं। अन्य विचार? - MikeBaz - MSFT
मुझे 0kb को ईमेल आकार सीमा भेजने / प्राप्त करने की सेटिंग पसंद है। - mrdenny
@mrdenny: यह उपयोगकर्ताओं को अपने स्वयं के "ड्राफ्ट" या "प्रेषित आइटम" फ़ोल्डरों में डेटा को गिलहराने से नहीं रोकता है। वे संदेश नहीं भेज सके लेकिन वे अभी भी अपने मेलबॉक्स में जानकारी जोड़ने में सक्षम होंगे। - Evan Anderson