Exchange Server 2010 New-MailMessage

by Arman Obosyan 2. August 2009 01:11

…довольно полезный cmdlet которого явно не хватало, New-MailMessage, применение которому можно найти в разных задачах, к примеру создание в EMS пользователей и отсылка им сообщения, или...

New-MailMessage

Exchange Server 2010 (14.0.xxx.xx)

NAME
New-MailMessage

SYNOPSIS
The New-MailMessage cmdlet creates a new e-mail message for the specified user mailbox placing the e-mail message in the Drafts folder of the user's mailbox.

SYNTAX
New-MailMessage [-Body <String>] -Mailbox <MailboxIdParameter> [-BodyFormat <PlainText | Html | Rtf>] [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-Subject <String>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

DESCRIPTION
If the cmdlet is run without specifying the subject or body parameters, an empty e-mail message is placed in the user's Drafts folder. You need to be assigned permissions before you can run this cmdlet. Although all parameters for this cmdlet are listed in this topic, you may not have access to some parameters if they're not included in the permissions assigned to you. To see what permissions you need, see the "User reporting" entry in the Client Access Permissions topic.

Exchange Server 2010 More PowerShell !

by Arman Obosyan 11. May 2009 13:52

e14-ps00

Больше PowerShell-а, еще больше! Я бы начал очередную заметку про Exchange Server 2010 с этих слов, впрочем  что я уже сделал :-)

Для меня PowerShell это то чего мне всегда не хватало в администрировании (думаю и для других тоже) с выходом Exchange Server 2007 в этом убедились все администраторы Exchange Server, рассказывать о прелестях и возможностях PowerShell выходит за рамки моего стиля Pauca Verba (немногословно) да и в интернете вы найдете много профессионально написанных статей на эту тему, а мне дилетанту в этом деле (написании статей, заметок) хочется рассказать о новых приятных “фишках” добавленных в Exchange Server 2010 (далее E14) по части PowerShell (PS)

Пожалуй самое первое что заметит администратор после установки E14 по части PowerShell это то что иконок запуска окна Exchange Management Shell (EMS) стало два! (2) Почему два? (а я вот о чем, Больше PowerShell-а, еще больше!)

Exchange Management Shell

Exchange Management Shell (Local Powershell)

Дело в том что в E14, PowerShell всегда соединяется с сервером через Internet Information Server к каталогу powershell, независимо от того, вы подключаетесь на локальный сервер или на удаленный сервер, тут WinRM является механизмом связи между Shell сессией и сервером E14.

При запуске Exchange Management Shell, происходит подключение к серверу и загрузка доступных cmdled-ов с сервера

Пример подключения EMS к серверу,

e14-ps02 e14-ps01

По умолчанию ярлык запуска EMS содержит параметры

'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"

Как нетрудно догадаться что делает -auto, можно создать дубликат ярлыка с параметрам (пример) Connect-ExchangeServer -ServerFQDN e14ex02.corp.postmaster.ge и после запуска работать сразу с удаленным сервером, или в уже запушенном окне переключатся меж серверами (или организациями) командой Connect-ExchangeServer, стоит заметить что данная команда доступна только в RemoteExchange.ps1.

Вы наверно подумаете для чего так намудрили и теперь подключение происходит таким вот образом, а сделано это потому что была ведена Role Based Access Control (RBAC) которая после проверки вашего доступа и делегированных вам прав, позволяет работать в повершелл только с теми cmdled-ами на роли которых вы имеете права, тем самым при запуске вы получаете своё окружение PS.

Также стоит заметить что теперь и Exchange Management Console (EMC) работает по принципу соединения IIS и работа WinRM независимо от того, вы подключаетесь на локальный сервер или на удаленный сервер

Пример подключения EMC к другому серверу или тут про Exchange Online

e14-ps04 e14-ps03

Тут также присутствует RBAC и вы получаете только то что вам дано и не более.

Вы спросите а как же локальная работа на сервере? Для этого мы используем Exchange Management Shell (Local Powershell) который использует уже знакомый нам 'C:\Program Files\Microsoft\Exchange Server\V14\bin\Exchange.ps1'

Тут все как раньше

e14-ps05

Кстати кто устанавливал Exchange Server 2010 Beta на Windows Server 2008 R2 RC (6.1.7100) наверно встретился с несовместимостью в работе WinRM+PowerShell,

Вот тут то и спасает Exchange Management Shell (Local Powershell) которая работает исправно а вот о EMC и EMS сказать подобное пока нельзя, обещали исправить в следующих версиях E14.

Что еще спросите вы, обратите внимание на окно свойства пользователя, значок PowerShell, теперь все что было изменено можно видеть как это выглядит в PS

 e14-ps07 e14-ps08

Тем самым можно к примеру не зная как это делается с PS всегда научится у того же EMC, далее вам уже нечего не стоит придумать некий ваш скрипт и “за пэйплайнить” несколько скриптов сразу. Очень полезно тем кто незнаком с повершел, можно всегда видеть что происходит на самом деле в PowerShell

Больше PowerShell-а, еще больше!? Ага, вот еще, теперь все проделанные команды можно видит еще и виде лога проделанной работы, все действия проделанные с консоли EMC, логируются в отдельном окне и по завершению работы можно сохранить и заодно посмотреть что же вы 3-мя кликами мыши наделали в повершеле,

e14-ps09 e14-ps10

e14-ps11

 

Еше PowerShell? А как вам логии всего что происходит в PowerShell так еще и в удобном доступном месте к примеру в почтовом ящике?

 

Новая фишка Administrator Audit Logging, как она работает? Для начала сконфигурируем ее,

Запускаем наш Exchange Management Shell (Local Powershell) и набираем

e14-ps12

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True

И на заранее созданный почтовый ящик adminauditlog@postmaster.ge направляем наши PowerShell логии

Set-AdminAuditLogConfig -AdminAuditLogMailbox adminauditlog@postmaster.ge

Теперь все проделаные нами действия будут приходить нам на заданыый почтовый яшик,

 e14-ps13 e14-ps14

Подробно о команде Set-AdminAuditLogConfig можно как всегда посмотреть командой get-help Set-AdminAuditLogConfig –full, можно сконфигурировать на запись в лог конкретных действий к примеру только set* или set-mailbox* и так далее.

И в заключении я могу сказать одно что в Exchange Server 2010 для начинающих только работать в Exchange Management Shell открываются новые возможности в изучении и познании работы EMS, если раньше мы могли довольствоваться только “выходным содержимым завершившейся команды в визарде” и ее копированием, то теперь можно пожалуй в любом месте сменив любой параметр предварительно увидеть как это выглядит в PowerShell, видеть что происходит на протяжении всей сесии работы, команды повершела, логировать их и получать на маил, ну и теперь скажите что EXCHANGE ROCKS! :-)

 

[addlang]

 

 

e14-ps00 მეტი PowerShell, კიდე უფრო მეტი! ამ სიტყვებით მინდა დავიწყო ეს სტატია Exchange Server 2010 – ს შესახებ. :-)

 PowerShell ჩემთვის არის ის, რაც ყოველთვის მაკლდა ადმინისტრირებაში (ალბათ ამაში ბევრი მკითხველი დამეთანხმება), Exchange Server -ის ადმინისტრატორები ამაში დარწმუნდნენ Exchange 2007-ს გამოსვლის თანავე. არ დავიწყებ მოყოლას PowerShell–ის საშუალებების და უპირატესობების შესახებ, რადგან ეს არ შეესაბამება ჩემ სტილს Pauca Verba (მოკლედ და კონკრეტულად), მითუმეტეს ინტერნეტში არის ბევრი პროფესიონალური სტატია ამ თემაზე, მე კი, როგორც დილეტანტი სტატიების დაწერის საკითხში მინდა მოვყვე PowerShell (PS) -თან დაკავშირებულ სასიამოვნო ახალ მომენტებზე , რომლებიც დაემატა Exchange Server 2010–ს (შემდეგში E14).

ყველაზე მთავარი და თვალსაჩინოა ის ფაქტი, რომ დაყენების თანავე ვხედავთ Exchange Management Shell (EMS) - ის ორ (2) პიქტოგრამას. რატომ ორს? მეც ამას ვამბობ – მეტი PowerShell, კიდე უფრო მეტი!

Exchange Management Shell

Exchange Management Shell (Local Powershell)

საქმე იმაშია, რომ E14-ში PowerShell ყოველთვის უკავშირდება სერვერზე PowerShell–ის კატალოგს Internet Information Server–ის გავლით, არა აქვს მნიშვნელობა როგორ ხდება დაკავშიდება – ლოკალურად თუ დისტანციურად. ამ შემთხვევაში WinRM აკავშირებს PowerShell-ის სესიას და E14-ს.

EMS- ის გაშვების თანავე მყარდება კავშირი სერვერთან და სერვერიდან იშვება ხელმისაწვდომი cmdlet-ები. EMS და სერვერის კონექტის მაგალითი:

e14-ps02 e14-ps01

EMS- ის შორტქატი ავტომატურად შეიცავს პარამეტრებს :

'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"

-auto –ს ფუნქცია თვალსაჩინოა, შესაძლებელია შორტქატის დუბლიკატის შექმნა შემდეგი პარამეტრით : Connect-ExchangeServer -ServerFQDN e14ex02.corp.postmaster.ge და გაშვების თანავე ვიმუშავოთ სერვერზე დისტანციურად, ან შესაძლებელია უკვე გაშვებულ ფანჯარაში მოვახდინოთ გადართვა სხვა სერვერზე (ან ორგანიზაციაზე) Connect-ExchangeServer ბრძანების საშუალებით. ავღნიშნავ, რომ ეს ბრძანება ხელმისაწვდომია მხოლოდ RemoteExchange.ps1–ში.

ალბათ დაგაინტერესებთ ამ დამატებითი პარამერტის აზრი, ეს გახლავთ სერვისი Role Based Access Control (RBAC) – ს გამოყენება, რომელიც დაკავშირების თანავე ამოწმებს თქვენ წვდომას და თქვენზე დელეგირებულ უფლებეს, ამ შემოწმების შემდეგ Role Based Access Control (RBAC) გაძლევთ საშუალებას გამოიყენოთ მხოლოდ ის cmdlet-ები, რომელზეც გაქვთ წვდომა – ანუ EMS -ის გაშვებისას იღებთ თქვენთვის განკუთვნილ PS გარემოებას.

ასევე აღსანიშნავია, რომ ეხლა უკვე Exchange Management Console (EMC)–ც მუშაობს IIS-თან დაკავშირების პრინციპით და WinRM – ის მუშაობა არ არის დამოკიდებული იმაზე, თუ როგორ ხდება კონექტი – ლოკალურად თუ დისტანციურად.

იხილეთ EMC-ს დაკავშირების მაგალითი აქ ან აქ Exchange Online

e14-ps04 e14-ps03

აქაც მუშაობს RBAC და ღებულობთ მხოლოდ შესაბამის გარემოებას.

ალბათ გაგიჩნდებათ კითხვა სერვერზე ლოკალური მუშაობის შესახებ. ამისთვის გამოიყენება Exchange Management Shell (Local Powershell) ჩვენთვის უკვე ნაცნობი პარამეტრით: 'C:\Program Files\Microsoft\Exchange Server\V14\bin\Exchange.ps1'

აქ ყველაფერი ძველებურად არის :

e14-ps05

სხვათაშორის, ვინც დააყენა Exchange Server 2010 Beta Windows Server 2008 R2 RC (6.1.7100)–ზე შეამჩნევდა შეუთავსებლობას მუშაობაში WinRM+PowerShell. აქ გვეხმარება Exchange Management Shell (Local Powershell), რომელიც კარგად მუშაობს, EMS და EMC–ზე მაგას ჯერჯერობით ვერ ვიტყვი, მაგრამ Microsoft გვპირდება ამის გასწორებას E14 – ს შემდეგ ვერსიებში.

Что еще спросите вы, დაუკვირდით მომხმარებლის თვისებების (Mailbox Properties) ფანჯარას. ქვემოდ მოთავსებულია PowerShell-ის პიქტოგრამა, რომლის საშუალებით შეგვიძლია ვნახოთ როგორ გამოიყურება ესა თუ ის ცვლილება PowerShell–ში.

 e14-ps07 e14-ps08

ეს ძალიან სასარგებლოა იმათთვის, ვინც PS-ში ნაკლებად ერკვევა – თუ ვერ ვაკეთებთ გარკვეულ მოქმედებებს PS – ში შეგვიძლია გავაკეთოთ იგივე EMC – ში და ვნახოთ შესაბამისი კოდი.

მეტი PowerShell, კიდე უფრო მეტი? მართალია – ეხლა ყველა შესრულებული ბრძანების ლოგიც შეგვიძლია ვიხილოთ ცალკე ფანჯარაში და შევინახოთ ის მუშაობის დასრულების თანავე.

e14-ps09 e14-ps10

e14-ps11

კიდე PowerShell? და როგორ მოგწონთ ის, რომ ლოგი შეიძლება თხვენთვის მოხერხებულ ფორმაში მიიღოთ – მაქალითად თქვენ საფოსტო ყუთში?

ამისთვის გამოიყენება ახალი საშუალება Administrator Audit Logging,პირველ რიგში მოვახდინოთ მისი კონფიგურაცია. Exchange Management Shell (Local Powershell)–ში

ჩავწეროთ :

e14-ps12

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True

და ვაგზავნით ლოგებს წინასწარ გამზადებულ მეილბოქს–ში adminauditlog@postmaster.ge направляем наши PowerShell логии

Set-AdminAuditLogConfig -AdminAuditLogMailbox adminauditlog@postmaster.ge

ახლა ყველა შესრულებული მოქმედების ლოგი გაიგზავნება ამ საფოსტო ყუთში.

 e14-ps13 e14-ps14

უფრო დაწვრილებითი ინფორმაცია Set-AdminAuditLogConfig ბრძანების შესახებ შეგვიძლია მივიღოთ სტანდარტულად – EMS- ში get-help Set-AdminAuditLogConfig –full სტრიქონის აკრეფით. ასევე შესაძლებელია ლოგ ფაილში მხოლოდ კონკრეტული მოქმედებების შესახებ ინფორმაციის ჩაწერა, მაგ. მხოლოდ set* ან set-mailbox* და ა.შ.

საბოლოოდ შემიძლია ავღნიშნო, რომ Exchange Server 2010 აძლევს ახალ საშუალებებს EMS –ში ნაკლებად გამოცდილ ადმინისტრატორებს ბევრად უფრო ღრმად შეისწავლონ EMS-ის მუშაობის პრინციპი. თუ ადრე შესაძლებელი იყო მხოლოდ დასრულებული ბრძანების EMS კოდის ნახვა ვიზარდში და მისი კოპირება, ეხლა უკვე შესაძლებელია მუშაობის პროცესში ნებისმიერ მომენტში ნებისმიერი პარამერტის შეცვლის თანავე ნახვა თუ როგორ გამოიყურება შესაბამისი EMS კოდი, ლოგირება და ლოგის მეილზე გადაგზავნა, ასე რომ ალბათ დამეთანხმებით

 EXCHANGE ROCKS! :-)

 

©Translated by Evgenia Prikhodko

Exchange Server 2010 EMC, Exchange Online, Manage Recipients,

by Arman Obosyan 24. April 2009 12:47

ExchangeSvr_h_rgb_22 После выхода Exchange Server 2010 Beta, нам стала доступна консоль управления (и многое другое!), с ее помощью мы можем администрировать пользовательские майлбоксы которые размешены на Microsoft Exchange Labs!

Как пример я попробовал добавить postmaster.ge на администрирование средствами консоли которая идет с Exchange Server 2010 Beta, для начала нам нужна установить саму консоль управления, или можно работать с любого E14 сервера который у вас уже установлен, если нет, то уже самое время устанавливать! (сам процесс установки уже был описан многими, вы можете прочитать об этом тут) добавлю что нам для администрирования Exchange Labs нужна только консоль управления (естественно WinRM 2.0 не ниже CTP3 и PowerShell V2 CTP3, что собственно и требуется при инсталляции Exchange Server 2010)

Для начала проверим доступ до Exchange Labs средствами PоwerShell а затем добавим его в консоль Exchange Server 2010, Запускаем PowerShell, удостоверяемся что PowerShel может выполнять удаленные команды Get-ExecutionPolicy если результат не RemoteSigned то устанавливаем Set-ExecutionPolicy RemoteSigned

 image

В окне PowerShell $LiveCred = Get-Credential , на что получаем окно ввода пользователя и пароля для администрирование Exchange Labs

image

Подключаемся к серверу $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection  

image

Параметр AllowRedirection помогает нам подключатся по одному url к любым серверам И импорт cmdled-ов Import-PSSession $Session проверяем, по завершению тестирования закрываем сесcию командой Remove-PSSession $Session  

image

Теперь можно смело подключатся через Exchange Management Console, запускаем  

image

В поле Specify a friendly name for this Exchange forest: указываем название или любое значение по вашему усмотрению Select the type of Exchange deployment: выбираем Microsoft Exchange Online, в поле Administrator указываем учетную запись администратора, пароль, и указываем url удаленного PowerShell Если вы были переадресован на другой сервер когда подключались через PowerShell то тут нужно указывать именно тот url на который вы были переадресованы, после подключения мы увидим:

image image image 

 Таким образом с новым Exchange Server 2010 мы можем администрировать как локальные и удаленные сервера в организации так и за пределами, будь то Exchange Labs или сервера других Exchange организаций или…., ну понятно :)

Радует то что с Exchange Server 2010 нам дается возможность администрировать с WEB (через ECP), PowerShell и Management Console, как локально так и удалено!melbas

EXCHANGE ROCKS!

 

 

[addlang]

 

ExchangeSvr_h_rgb_22Exchange Server 2010 Beta -ს გამოსვლისას ჩვენთვის ხელმისაწვდომი გახდა მართვის კონსოლი (და არა მხოლოდ ეს!) , რომლოს საშუალებით შეგვიძლია ადმინისტრირება სამომხმარებლო მეილბოქსების, რომლების განთავსებულია Microsoft Exchange Labs–ში!

მაგალითისთვის ვცაცე postmaster.ge–ს დამატება ადმინისტრირებაში. ამისთვის გამოვიყენე კონსოლი, რომელიც შედის პაკეტში Exchange Server 2010 Beta. პირველ რიგში უნდა დავაყენოთ ეს კონსოლი, სხვა შემთხვევაში შეიძლება ნებისმიერი თქვენი დაყენებული E14–ს გამოყენება, თუ E14 ჯერ არ  დაგიყენებიათ, დროა დააყენოთ (დაყენების პროცესის აღწერა შეგიძლიათ იხილოთ აქ). დავამატებ, რომ Exchange Labs – ის ადმინისტრირებისთვის საკმარისია მხოლოდ მართვის კონსოლი (და რა თქმა უნდა WinRM 2.0 არა ნაკლები CTP3–ს და PowerShell V2 CTP3, რაც Exchange Server 2010–ს სჭირდება).

პირველ რიგში შევამოწმოთ წვდომა Exchange Labs–მდე PоwerShell საშუალებით, შემდეგ დავამატებთ მაგას კონსოლში Exchange Server 2010. ვუშვებთ PоwerShell–ს, ვრწმუნდებით, რომ შეიძლება დისტანციური ბრძანებების შესრულება:

Get-ExecutionPolicy

 image

შემდეგ ვწერთ $LiveCred = Get-Credential, რის შედეგად ვიღებთ აუტენტიფიკაციის ფანჯარას:

image

ვუკონექტდებით სერვერს:

 $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic –AllowRedirection  

image

AllowRedirection პარამეტრი გვაძლებს საშუალებას გამოვიყენოთ ერთი url სხვადასხვა სერვერებთან დაკონექტებისთვის.

სევე ვაკეთებთ Import-PSSession $Session cmdled–ების იმპორტისთვის

ვამოწმებთ გამართულ მუშაობას:

image

ეხლა განვიხილოთ კონექთი Exchange Management Console–ის გამოყენებით:

image

ველში Specify a friendly name for this Exchange forest ვუთითებთ დასახელებას ან ნებისმიერ მნიშვნელობას თქვენი გემოვნებით.

Select the type of Exchange deployment: Microsoft Exchange Online, Administrator: ადმინისტრატორის იუზერნეიმი, Password: პაროლი და ქვემოდ ვუთითებთ დისტანციური PowerShell–ის url–ს.

თუ PowerShell–ით კონექტის დროს მოხდა თქვენი გადამისამართება სხვა სერვერზე, მაშინ აქ უნდა მიუთითოთ ის url, რომელზეც მოხდა გადამისამართება. კონექთის დამყარების შემდეგ ვხედავთ შემდეგ სურათს:

image image image 

ასე რომ ახალ Exchange Server 2010–ით შეიძლება როგორც ლოკალური, ასევე დისტანციური სერვერების ადმინისტრირება, როგორც ჩვენ ორგანიზაციაში, ასევე მისი ფარგლების გარეთ, არა აქვს მნიშვნელობა ეს იქნება Exchange Labs, ან სხვა Exchange ორგანიზაციების სერვერები, და ა.შ.

სასიამოვნოა ის ფაქტიც, რომ გვეძლევა WEB ადმინისტრტრირების საშუალება (ECP–ს საშუალებით), PowerShell და Management Console ლოკალურად და დისტანციურად!

melbas

EXCHAGNE ROCKS!

 

©Translated by Evgenia Prikhodko

 

 

© 2008-2012, Arman Obosyan, Postmaster.GE
Powered by BlogEngine.NET 2.6.0.18
Hosted on Windows Azure and IIS8

About the author

Arman Obosyan have more than 20+ years’ work experience in Information Technologies sector.

Last few years he working on a position Technology Strategist at Microsoft Corporation, In the past Arman was Head of IT Infrastructure in Governmental Central Bank of Georgia (National Bank of Georgia).

Nowadays Arman is supporting C-Level and enabling business, visionary with a passion of technology, trends.

---

Certified since 2003 year, passed following certifications MCP, MCSA, MCSE, MCTS, MCITP, Exin ITIL and VMware Certified Professional (VCP)

Founder / Lead of Microsoft Certified Professionals (MCP) Club Tbilisi and Community GE project 

In 2010 Was awarded a Microsoft Most Valuable Professional (MVP)

2017 MVP Reconnect

--------

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent anyone else's view in any way, including those of my employer.



Live Trafic

 

Calendar

<<  April 2019  >>
MoTuWeThFrSaSu
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

View posts in large calendar

TextBox