tag:blogger.com,1999:blog-31749863915578834282024-03-13T14:49:26.535-07:00Farhad's Technical Tips and TricksThe purpose of this blog is to be helpful for many professionals looking for a tricky solutions that do not happen every dayAnonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.comBlogger142125tag:blogger.com,1999:blog-3174986391557883428.post-36383374489456551212017-07-04T03:37:00.001-07:002017-07-04T03:37:16.144-07:00Using PowerShell To Retrieve IP Addresses for Exchange Servers<div dir="ltr" style="text-align: left;" trbidi="on">
Hi Folks,<br />
<br />
In this short post I will share with you a command on how to retrieve list of IP addresses for your Exchange servers. As you will see below it's very straightforward. It simply pipes all hostnames and then resolves each of them from DNS:<br />
<br />
<b>Get-ExchangeServer |foreach {Resolve-DnsName $_.Name -NoHostsFile -Type A} |select Name,IPAddress</b><br />
<br />
You will get a nice output like below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-1QRG7yXqTwk/WVtv10LReZI/AAAAAAAABd8/FzMrux7_wRse0meSQOB-BE4TlssecpU0gCLcBGAs/s1600/IPAddr01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="121" data-original-width="934" height="41" src="https://3.bp.blogspot.com/-1QRG7yXqTwk/WVtv10LReZI/AAAAAAAABd8/FzMrux7_wRse0meSQOB-BE4TlssecpU0gCLcBGAs/s320/IPAddr01.PNG" width="320" /></a></div>
<br />
<br />
Alternatively you can use Export-Csv command to export your results to CSV file if you need any further processing or reporting of this data.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-15999627559705302892017-06-20T08:14:00.004-07:002017-06-20T08:15:02.674-07:00Quickly Checking Account Lockout State<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
In this very quick post I wanted to share with you a quick retrieving of the account lockout status for an user account in the AD. It can be found by running the below simple command:<br />
<b><br /></b>
<b>Get-ADUser "User1" -Properties LockedOut |select Name,LockedOut</b><br />
<br />
And will result in a simple output as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-gGmV5dB6pgY/WUk7nEvKjdI/AAAAAAAABdE/qI1CbZmBjGwcSTeS8uSD_J02QBdzgJKvgCLcBGAs/s1600/Lock01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="89" data-original-width="848" height="33" src="https://2.bp.blogspot.com/-gGmV5dB6pgY/WUk7nEvKjdI/AAAAAAAABdE/qI1CbZmBjGwcSTeS8uSD_J02QBdzgJKvgCLcBGAs/s320/Lock01.PNG" width="320" /></a></div>
<br />
If the value for the LockedOut is False then account is not locked and if it is True, then it is locked. Which is pretty obvious.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-91804741126174421242017-06-06T08:21:00.003-07:002017-06-06T08:21:33.358-07:00Cumulative Updates and Recovery Databases<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
I want to share about another adventure which I have had with the installation of the latest CU on Exchange 2016. During installation of CU and in particular during configuration of the Mailbox services component installation failed with the error as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-8Vj85ywkNQM/WTbD-f6psWI/AAAAAAAABcQ/LFMtsW9I0LI_fxhJISZyBHVlyFpA-ZqmgCLcB/s1600/CUDB02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="618" data-original-width="651" height="303" src="https://4.bp.blogspot.com/-8Vj85ywkNQM/WTbD-f6psWI/AAAAAAAABcQ/LFMtsW9I0LI_fxhJISZyBHVlyFpA-ZqmgCLcB/s320/CUDB02.PNG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-KH2Oh8m4Iy0/WTbD-TJ89aI/AAAAAAAABcM/uVbymSMIsjgJwDZXsLNLBKHqre_QJnUqQCEw/s1600/CUDB01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="939" data-original-width="648" height="320" src="https://1.bp.blogspot.com/-KH2Oh8m4Iy0/WTbD-TJ89aI/AAAAAAAABcM/uVbymSMIsjgJwDZXsLNLBKHqre_QJnUqQCEw/s320/CUDB01.PNG" width="220" /></a></div>
<br />
<br />
In couple of words at this stage installation is checking availability of the arbitration mailboxes, and if they're not available, it tries to create them and configure quotas and SCL related settings.<br />
<br />
According to this error for some reason Exchange setup program has attempted to configure arbitration mailbox in the recovery database. Probably it was the first retrieved from the list of DBs located on the server and since recovery DB can't store mailboxes setup program had failed.<br />
<br />
In my case to solve it I had to remove it by running a command similar the the below:<br />
<br />
<b>Get-MailboxDatabase "RecoveryDB001" |Remove-MailboxDatabase -Confirm:$false</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-rNBrHDNDHN8/WTbEvKfZbjI/AAAAAAAABcY/gEXmmclEseQQ83AT4WXdOc6cuEBrf_4TACLcB/s1600/CUDB03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="56" data-original-width="937" height="19" src="https://4.bp.blogspot.com/-rNBrHDNDHN8/WTbEvKfZbjI/AAAAAAAABcY/gEXmmclEseQQ83AT4WXdOc6cuEBrf_4TACLcB/s320/CUDB03.PNG" width="320" /></a></div>
<br />
After this installation should proceed.<br />
<br />
However in my cases there was a problem with AD replication and it was not properly removed from the AD. Therefore the error above would still pop up at every time I tried to re-run the installation program. In the log I have discovered domain controller which install program tried to use and navigated to the path of the DB as below:<br />
<br />
<b>CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CONTOSO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com</b><br />
<br />
After manual deletion of a DB object from the AD installation had proceeded successfully.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-Ol8qF_Osu7I/WTbIZBVdNuI/AAAAAAAABck/EGtsx5KzOjcXZTbWWxw6Kny346XVEvmogCLcB/s1600/CUDB07.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="552" data-original-width="673" height="262" src="https://1.bp.blogspot.com/-Ol8qF_Osu7I/WTbIZBVdNuI/AAAAAAAABck/EGtsx5KzOjcXZTbWWxw6Kny346XVEvmogCLcB/s320/CUDB07.PNG" width="320" /></a></div>
<br />
Enjoy</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com1tag:blogger.com,1999:blog-3174986391557883428.post-25810880816411603292017-06-06T07:13:00.002-07:002017-06-06T07:13:32.269-07:00Save Your Time Typing Local Hostname<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
This is probably my shortest blog post. If you are just lazy as I am and if you employ a hard-to-remember naming convention for your computers and servers there is a default variable $env:COMPUTERNAME which retrieves local computers hostname. So for example if you want to run a command to check health of the local Exchange server this command will be at your disposal:<br />
<br />
<b>Get-ServerComponentState -Identity $env:COMPUTERNAME</b><br />
<b><br /></b>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-LLUv-aofSIU/WTa4hCscOCI/AAAAAAAABb8/2GFMDJW5KKk0U1x0J9LZBGqajOKMkfmqACLcB/s1600/Variable.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="467" data-original-width="802" height="186" src="https://2.bp.blogspot.com/-LLUv-aofSIU/WTa4hCscOCI/AAAAAAAABb8/2GFMDJW5KKk0U1x0J9LZBGqajOKMkfmqACLcB/s320/Variable.PNG" width="320" /></a></div>
<b><br /></b>
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-74122024680025827382017-06-02T10:03:00.002-07:002017-06-02T10:03:17.758-07:00Another BackEnd Site Fixing (This Time for PowerShell)<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
I have already shared in <a href="http://farkhadm.blogspot.co.uk/2017/03/fixing-broken-backend-site.html" target="_blank">this post</a> about my adventures with Exchange Management Shell and other CAS protocols which are caused by misconfigured back end web site on an Exchange 2016 Mailbox server.<br />
<br />
Recently I have had yet another adventure. When launching Exchange Management Shell I saw the following error and PowerShell connected to another Exchange server in the same AD site:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-J_AGu7QuhbQ/WTGYqwm6sEI/AAAAAAAABbQ/WjPJcWEjQmAmA5Cb3pJyrTc-0FbipujRQCLcB/s1600/PS_IIS_Bind01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="835" data-original-width="955" height="279" src="https://1.bp.blogspot.com/-J_AGu7QuhbQ/WTGYqwm6sEI/AAAAAAAABbQ/WjPJcWEjQmAmA5Cb3pJyrTc-0FbipujRQCLcB/s320/PS_IIS_Bind01.PNG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-zyNkkD2C-kg/WTGYwnPWKUI/AAAAAAAABbU/xupEklDsLb8Cfrc_ktuDPsrc1ToV0bmtACLcB/s1600/PS_IIS_Bind03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="239" data-original-width="947" height="80" src="https://2.bp.blogspot.com/-zyNkkD2C-kg/WTGYwnPWKUI/AAAAAAAABbU/xupEklDsLb8Cfrc_ktuDPsrc1ToV0bmtACLcB/s320/PS_IIS_Bind03.PNG" width="320" /></a></div>
<br />
Furthermore, I have discovered in the Application log the error event 1003 for Microsoft Front End HTTP Proxy followed by the warning event 1309 for ASP.NET:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-K_W6cB_FTu4/WTGZLzph7oI/AAAAAAAABbY/Da69f0LPKtkoXH7ACXx_HZxQIwitKGFcwCLcB/s1600/PS_IIS_Bind06.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="258" data-original-width="931" height="88" src="https://3.bp.blogspot.com/-K_W6cB_FTu4/WTGZLzph7oI/AAAAAAAABbY/Da69f0LPKtkoXH7ACXx_HZxQIwitKGFcwCLcB/s320/PS_IIS_Bind06.PNG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-Lu2l3vY87o8/WTGZOWD-vMI/AAAAAAAABbc/TKyD-2-PW28PrNGXf7sAjTq_gXDqh6ppACLcB/s1600/PS_IIS_Bind07.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="653" data-original-width="999" height="209" src="https://4.bp.blogspot.com/-Lu2l3vY87o8/WTGZOWD-vMI/AAAAAAAABbc/TKyD-2-PW28PrNGXf7sAjTq_gXDqh6ppACLcB/s320/PS_IIS_Bind07.PNG" width="320" /></a></div>
<br />
My investigation has lead me to <a href="http://exchangeitup.blogspot.co.uk/2016/12/exchange-2016-management-shell-wont.html" target="_blank">this article</a> according to which this is caused by misconfigured certificate on the Exchange Back End web site. This can be easily seen when the binding for port 444 is checked:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-Pievoh_0dKE/WTGZv_SX6iI/AAAAAAAABbg/L-C2a3RKJ94Ci9YNzQpVsWeA4kZX7HoXgCLcB/s1600/PS_IIS_Bind02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="318" data-original-width="550" height="185" src="https://2.bp.blogspot.com/-Pievoh_0dKE/WTGZv_SX6iI/AAAAAAAABbg/L-C2a3RKJ94Ci9YNzQpVsWeA4kZX7HoXgCLcB/s320/PS_IIS_Bind02.PNG" width="320" /></a></div>
<br />
All you need to do is to select the self signed certificate with the friendly name of "Microsoft Exchange" and click OK button:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-8ZoG_JM4y1c/WTGaIYJVhdI/AAAAAAAABbk/6gI4UAP7VvYtqSeFd9vMFb5Nqm93dFkTwCLcB/s1600/PS_IIS_Bind04.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="326" data-original-width="543" height="192" src="https://2.bp.blogspot.com/-8ZoG_JM4y1c/WTGaIYJVhdI/AAAAAAAABbk/6gI4UAP7VvYtqSeFd9vMFb5Nqm93dFkTwCLcB/s320/PS_IIS_Bind04.PNG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-8hQz83mCIzU/WTGaJ7GC9eI/AAAAAAAABbo/hsQPNI8UPLsJtquHr--I4tquuFOj-G5vgCLcB/s1600/PS_IIS_Bind05.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="327" data-original-width="545" height="192" src="https://1.bp.blogspot.com/-8hQz83mCIzU/WTGaJ7GC9eI/AAAAAAAABbo/hsQPNI8UPLsJtquHr--I4tquuFOj-G5vgCLcB/s320/PS_IIS_Bind05.PNG" width="320" /></a></div>
<br />
After this you will need to run IIS reset or restart the server after which Exchange Management Shell can be accessed and used again.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-83549789833097890562017-06-01T10:23:00.001-07:002017-06-01T10:23:40.578-07:00Mailbox Exports Preventing Exchange 2010 Uninstallation<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
In this quick post I would love to share with you about my recent adventure. When uninstalling Exchange 2010 binaries I faced the following error:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-V-UVhVIlo_Q/WTBM8YDJZhI/AAAAAAAABbA/vlvi0FxhEFsfDshrjE67wnX_9XzzvPSBQCLcB/s1600/UninstExp01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="376" data-original-width="637" height="188" src="https://4.bp.blogspot.com/-V-UVhVIlo_Q/WTBM8YDJZhI/AAAAAAAABbA/vlvi0FxhEFsfDshrjE67wnX_9XzzvPSBQCLcB/s320/UninstExp01.PNG" width="320" /></a></div>
<br />
<br />
This error is self-explanatory and the below command should be executed for each mailbox database that is displayed in error message:<br />
<br />
<b>Get-MailboxExportRequest | ?{ $_.RequestQueue -eq "DB01" }. | Remove-MailboxExportRequest </b><br />
<br />
After which mailbox database can be removed:<br />
<br />
<b>Remove-MailboxDatabase DB01 -Confirm:$false</b><br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-46057537489833035702017-05-17T08:33:00.000-07:002017-05-17T08:34:58.464-07:00CAS Services and Remote PowerShell Fail on An Exchange 2016 Box<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
Hi folks,<br />
<br />
In this quick post I will share with you about fixing the error when CAS authentication related modules fail to start on a freshly installed Exchange 2016 server. When launching remote PowerShell I was greeted with the below error and redirected to another server in the same AD site:<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/--JpGijJot4g/WRxr6Dp_2GI/AAAAAAAABaM/tZnWnGYTzrIJ9R-KP2cu4fku9e6suX2_gCLcB/s1600/FailedPS01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="262" src="https://4.bp.blogspot.com/--JpGijJot4g/WRxr6Dp_2GI/AAAAAAAABaM/tZnWnGYTzrIJ9R-KP2cu4fku9e6suX2_gCLcB/s320/FailedPS01.PNG" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-k8pH5h-14yU/WRxtnGEMK7I/AAAAAAAABag/S4un8hjVYGwJL-arNz3OHQFJ4ILFkIZAgCLcB/s1600/FailedPs02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="169" src="https://3.bp.blogspot.com/-k8pH5h-14yU/WRxtnGEMK7I/AAAAAAAABag/S4un8hjVYGwJL-arNz3OHQFJ4ILFkIZAgCLcB/s320/FailedPs02.PNG" width="320" /></a></div>
<br />
<br />
Furthermore in the Event Log you will see that the error of loading DLL files for OWA authentication and failure of starting Exchange BackEnd site (ID 2268 and 2214):<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-7mUQdVKO4h4/WRxr6GPXhlI/AAAAAAAABaE/QXzm28BoMIsdzU2h-MHhQnSV1sXWLXrGgCLcB/s1600/FailedPS04.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="62" src="https://4.bp.blogspot.com/-7mUQdVKO4h4/WRxr6GPXhlI/AAAAAAAABaE/QXzm28BoMIsdzU2h-MHhQnSV1sXWLXrGgCLcB/s320/FailedPS04.PNG" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-Fb_5RkgJhIg/WRxr6vByEqI/AAAAAAAABaU/aYTG4kqodkE0Ea4hbwQXDf4xYRoCIGISgCLcB/s1600/FailedPs03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="80" src="https://1.bp.blogspot.com/-Fb_5RkgJhIg/WRxr6vByEqI/AAAAAAAABaU/aYTG4kqodkE0Ea4hbwQXDf4xYRoCIGISgCLcB/s320/FailedPs03.PNG" width="320" /></a></div>
<br />
<br />
<a href="https://support.microsoft.com/en-us/help/2619202/sbs-2008-sbs2011-owa,-remote-fails-with-http-error-500." target="_blank">This article</a> became very helpful. It pointed me to the missing path to the Exchange bin folder in the Path variable. On the server I was working on it was missing along with the other folders including paths to system folders. So from a healthy Exchange server I copied values of the Path variable and pasted them to the broken server, In my case it was something like below (in real life this of course may vary):<br />
<br />
<b>; ;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Dell\SysMgt\oma\bin;C:\Program Files\Dell\SysMgt\shared\bin;C:\Program Files\Dell\SysMgt\idrac;C:\Program Files (x86)\Symantec\Data Center Security Server\Agent\IPS\bin;C:\Program Files\BMC Software\Control-M Agent\Default\exe;C:\Program Files\HP\HP BTO Software\lib;C:\Program Files\HP\HP BTO Software\bin;C:\Program Files\HP\HP BTO Software\bin\win64;C:\Program Files\HP\HP BTO Software\bin\win64\OpC;C:\Program Files\Microsoft\Exchange Server\bin;C:\Program Files\Microsoft\Exchange Server\Bin\Search\Ceres\Native\;C:\Program Files\Microsoft\Exchange Server\Scripts;C:\Program Files\Microsoft\Exchange Server\Scripts</b><br />
<br />
I hope you will find this time saving for your troubleshooting and fixing activity.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-21341987076431060752017-03-22T12:28:00.001-07:002017-03-23T13:55:27.553-07:00Windows HotFixes for Skype for Business Installation<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
Just a short post on the installation of Skype for Business server. The hotfix from KB2982006 is listed among prerequisites server installation. However when the update is downloaded during the installation you will the message saying"This update is not applicable to your computer".<br />
<br />
According to <a href="https://blogs.technet.microsoft.com/uclobby/2015/07/11/prerequisite-kb2982006-not-satisfied-when-trying-to-install-sfb-server-2015/" target="_blank">this article</a> two more updates are needed for successful install of this hotfix. Below is sequence that the updates should be install in: first you install KB2919442, then KB2919355, which is the biggest one and finally KB2982006. You will need to reboot your server after the second and the third updates and your server is ready for installation.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-13609899672414248532017-03-22T07:03:00.000-07:002017-03-22T07:03:21.898-07:00Retrieve BitLocker Recovery Password Information PowerShell<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
I have recently spend quite a time investigating BitLocker technology and also implementing it for Exchange servers to protect drives on servers according to Microsoft's preferred architecture about which you can read <a href="https://blogs.technet.microsoft.com/exchange/2015/10/12/the-exchange-2016-preferred-architecture/" target="_blank">here</a>. You can also read <a href="https://blogs.technet.microsoft.com/exchange/2015/10/20/enabling-bitlocker-on-exchange-servers/" target="_blank">this article</a> on how to plan and implement BitLocker. So apart of this I will not comment much on this because this subject is covered there quite well.<br />
<br />
When configuring BitLocker on your computer or server drives you can chose to backup your recovery keys to the AD. This is very handy as you can easily retrieve them when needed from the AD. And if your AD environment is tightened well enough you can keep it secure.<br />
<br />
Now how do you check whether your BitLocker keys have been backed up to the AD or not. Obviously you can do it by using ADUC tool. However, if you are looking to create a dump of these keys ADUC may not be a very handy tool to use. After some investigation I have found <a href="https://ndswanson.wordpress.com/2014/10/20/get-bitlocker-recovery-from-active-directory-with-powershell/" target="_blank">this</a> and <a href="http://www.configmgr.no/2013/02/24/how-to-retrieve-bitlocker-recovery-information-from-ad-using-powershell-3-0/" target="_blank">this</a> articles which were the major sources of my inspirations. Capitalizing on them, I have put together the below code which retrieves information on the recovery keys from AD and dumps them to CSV file which can be later processed by Excel.<br />
<br />
<b>$usrInput = $(Get-WmiObject Win32_Computersystem).name</b><br />
<b>$objComputer = Get-ADComputer $usrInput</b><br />
<b>$objADObject = get-adobject -Filter * | Where-Object {$_.DistinguishedName -match $objComputer.Name -and $_.ObjectClass -eq "msFVE-RecoveryInformation"}</b><br />
<b>$objADObject |select DistinguishedName,Name,ObjectClass |Export-Csv D:\Scripts\RecPwd-Report.csv</b><br />
<br />
I hope you will find this little script useful for your BitLocker adventures as it applies to any Windows Server or client box.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-85853518048025081032017-03-13T11:18:00.002-07:002017-03-13T11:18:53.681-07:00Fixing Broken BackEnd Site<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
I would love to share with you my recent experience that I had with Remote PowerShell on an Exchange 2016 box. As you well know since Exchange 2013 Exchange server is using 2 web sites in IIS: Default WebSite and BackEnd. The prior is listening on ports 80 and 443 while the latter is listening on ports 81 and 444.<br />
<br />
In my case when I launched Exchange Management Shell I was greeted with the below error:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-D2xccc44f4Y/WMKoQRhudMI/AAAAAAAABYE/yKQPV6ScPOEKRbHiUh7o2fw178ZAWuUcACLcB/s1600/FailedBackEnd03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="276" src="https://4.bp.blogspot.com/-D2xccc44f4Y/WMKoQRhudMI/AAAAAAAABYE/yKQPV6ScPOEKRbHiUh7o2fw178ZAWuUcACLcB/s320/FailedBackEnd03.PNG" width="320" /></a></div>
<br />
My investigation led me to the following error events in System log<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-T_Bpt2fdde0/WMKogQacsUI/AAAAAAAABYI/nf7yrMQu4hUZOV_898Jhp5Pmdr0sgqXGgCLcB/s1600/FailedBackEnd04.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="77" src="https://1.bp.blogspot.com/-T_Bpt2fdde0/WMKogQacsUI/AAAAAAAABYI/nf7yrMQu4hUZOV_898Jhp5Pmdr0sgqXGgCLcB/s320/FailedBackEnd04.PNG" width="320" /></a></div>
<br />
<br />
And Application log:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-PWdaV7alWwY/WMKokDRIZ9I/AAAAAAAABYM/UlszMkvE7VAJ3tsr6_V_vf46P7H4wzAKwCLcB/s1600/FailedBackEnd05.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="67" src="https://4.bp.blogspot.com/-PWdaV7alWwY/WMKokDRIZ9I/AAAAAAAABYM/UlszMkvE7VAJ3tsr6_V_vf46P7H4wzAKwCLcB/s320/FailedBackEnd05.PNG" width="320" /></a></div>
<br />
<br />
<br />
The errors were pointing to the BackEnd site where actual data rendering and processing for all protocols including PowerShell. As I was looking for solution of this problem <a href="https://itthatshouldjustwork.blogspot.co.uk/2015/05/exchange-2013-blank-ecpowa-screen.html" target="_blank">this post</a> and this <a href="https://technet.microsoft.com/en-gb/library/cc727844(v=ws.10).aspx" target="_blank">TechNet article</a>. According to it we need to retrieve information of all certificates that are used by IIS. We will need to use the below command for it.<br />
<br />
<b>netsh http show sslcert</b><br />
<br />
You will get output as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/--kcL64VN5No/WMKpregGDbI/AAAAAAAABYY/Ldjmhmwrmq8xwLME4eOy9C4IG70hPr41gCLcB/s1600/FailedBackEnd01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://3.bp.blogspot.com/--kcL64VN5No/WMKpregGDbI/AAAAAAAABYY/Ldjmhmwrmq8xwLME4eOy9C4IG70hPr41gCLcB/s320/FailedBackEnd01.PNG" width="271" /></a></div>
<br />
<br />
When retrieved we will need to record certificate hash and application ID (appid) for 127.0.0.1:443. Usually I prefer to dump the above command to a test file to make it easier. Also I was not able to find a certificate which was listed for 0.0.0.0:444 in the certificate store of the affected server. So the certificate needs to be removed and replace with the existing one which is used for the Default Web Site.<br />
<br />
After this you will need to delete cert for the back-end site represented by 0.0.0.0:444 by running the below command:<br />
<br />
<b>netsh http delete sslcert ipport=0.0.0.0:444</b><br />
<br />
After cert has been removed we will need to configure certificate for our back-end web site to use the same certificate that is used by the Default Web Site. In the output above it is presented as 127.0.0.1:443.<br />
Let's imagine that certificate hash for 127.0.0.1:443<span style="color: #666666; font-family: "segoe ui" , sans-serif;"><span style="background-color: white; font-size: 12px;"> </span></span> is <b>1234567890abcdef3456787asabaec4e8ba</b> and application id is <b>"{1abc2e345-a14b-4c22-b022-59fc885b0974}"</b><br />
<br />
<b>netsh http add sslcert ipport=0.0.0.0:444 certhash=1234567890abcdef3456787asabaec4e8ba appid="</b><b>1234567890abcdef3456787asabaec4e8ba</b><b>"{1abc2e345-a14b-4c22-b022-59fc885b0974}"</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/--i8hVvuaT9A/WMbh7k_uCeI/AAAAAAAABYo/OQJfzrxYOGwzi3o2tXZ8dK8IpKuXlsOwACLcB/s1600/FailedBackEnd02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="30" src="https://2.bp.blogspot.com/--i8hVvuaT9A/WMbh7k_uCeI/AAAAAAAABYo/OQJfzrxYOGwzi3o2tXZ8dK8IpKuXlsOwACLcB/s320/FailedBackEnd02.PNG" width="320" /></a></div>
<br />
<br />
Make sure that all the brackets and quotes are in place.<br />
<br />
I hope you will find this article helpful.<br />
<br />
Enjoy!<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-6604312145418756192017-03-09T06:10:00.000-08:002017-03-09T06:10:07.207-08:00Exporting Mailboxes in Multi-Domain Environment<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
Just wanted to share with you about an issue I have recently encountered. In the AD forest which has multiple domains when remotely connected to Exchange server via PowerShell and running New-MailboxExportRequest command you may experience the issue as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-7qzu-g8BQR8/WMFfkjCwL_I/AAAAAAAABX0/32_LcAqMuaMd7IbUzi17-iKrvO-cDrVkACLcB/s1600/Export01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="55" src="https://2.bp.blogspot.com/-7qzu-g8BQR8/WMFfkjCwL_I/AAAAAAAABX0/32_LcAqMuaMd7IbUzi17-iKrvO-cDrVkACLcB/s320/Export01.PNG" width="320" /></a></div>
<br />
Basically, PowerShell will complain that it can't find mailbox on a DC from the same domain as Exchange server is. And this is because that by default EMS is by default talking to the same domain where Exchange servers are located and where it was launched. As I previously posted to see mailboxes cross forest you will need to execute this command:<br />
<br />
<b>Set-ADServerSettings -ViewEntireForest:$true</b><br />
<br />
However, in this case it doesn't become a magic bullet to solve the problem.<br />
<br />
Google-ing took me to <a href="https://social.technet.microsoft.com/Forums/exchange/en-US/a8013f0d-46ad-4bbf-ad1c-8f9807a4e85d/newmailboxexportrequest-object-couldnt-be-found?forum=exchangesvrgeneral" target="_blank">this thread</a> on MS TechNet forum. According to it in addition to seeing the whole forest you also need to talk to a domain controller in a child domain where your mailbox is located. So imagine and in the contoso.com forest you have a domain child.contoso.com which has Exchange mailboxes the code for exporting mailbox to PST file will be as follows;<br />
<br />
<b>Set-ADServerSettings -ViewEntireForest:$true</b><br />
<b>New-MailboxExportRequest user@child.contoso.com –FileName \\servername\pst\test.pst -DomainController DC01.child.contoso.com</b><br />
<br />
I hope you will find it useful.<br />
<br />
Enjoy!<br />
<div>
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-37481116756745770802017-03-02T11:18:00.001-08:002017-03-02T11:18:18.027-08:00And Back to the Subject of ActiveSync Devices Reporting<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
I have already shared with you about creating reports for Exchange ActiveSync devices using PowerShell. You can read <a href="http://farkhadm.blogspot.co.uk/2017/01/some-additions-to-my-old-activesync.html" target="_blank">this post</a> about it.<br />
<br />
I have recently discovered this reporting script for reporting ActiveSync devices published <a href="https://gallery.technet.microsoft.com/scriptcenter/Generate-Reports-for-59557b49" target="_blank">here </a>by Paul Cunningham. All the information about it can be found in the article as well as in <a href="http://practical365.com/exchange-server/powershell-script-activesync-device-report/" target="_blank">this</a> Paul's post. The script is amazing and perfectly fits the purpose.<br />
<br />
However, there're couple of the things that are missing in the script. First, if you have a multi-domain forest it is possible that not all of your mailboxes are retrieved and added to the report. To fix it you will need to edit the script and add the following line:<br />
<br />
<b>Set-AdServerSettings -ViewEntireForest:$true</b><br />
<br />
I have added this line after the section which loads Exchange 2013 management shell as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-P5E6FkK9DpI/WLhvQhGj3-I/AAAAAAAABXY/n6rGtZ3zS-MZ537IcHOb--Y9ly8cez-lwCLcB/s1600/EASReport02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="115" src="https://1.bp.blogspot.com/-P5E6FkK9DpI/WLhvQhGj3-I/AAAAAAAABXY/n6rGtZ3zS-MZ537IcHOb--Y9ly8cez-lwCLcB/s320/EASReport02.PNG" width="320" /></a></div>
<br />
<br />
This script is also good for creating ActiveSync reports from Office 365. However when trying to run this from my Windows 10 laptop I would be greeted with error like below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-uWhn1Pfdwx4/WLhvlDF4UCI/AAAAAAAABXc/iJMPkG1qXxMvUV_ofViB7ZpIovT5alYcACLcB/s1600/EASReport03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="11" src="https://1.bp.blogspot.com/-uWhn1Pfdwx4/WLhvlDF4UCI/AAAAAAAABXc/iJMPkG1qXxMvUV_ofViB7ZpIovT5alYcACLcB/s320/EASReport03.PNG" width="320" /></a></div>
<br />
<br />
This is quite easy to fix. Simply remove the whole section which loads on-premises EMS and run script from the remote PowerShell session connected to Office 365 endpoint. To be clear this is what you need to remove from the script to run it successfully against the cloud:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-XR_ypYhdLqk/WLhv5NgrBOI/AAAAAAAABXg/kiwDwpTLB6wko7MeuQ8NDBH_XYBjM0U2QCLcB/s1600/EASReport01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="105" src="https://1.bp.blogspot.com/-XR_ypYhdLqk/WLhv5NgrBOI/AAAAAAAABXg/kiwDwpTLB6wko7MeuQ8NDBH_XYBjM0U2QCLcB/s320/EASReport01.PNG" width="320" /></a></div>
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-48088120670977170472017-03-02T10:56:00.001-08:002017-03-02T10:56:07.933-08:00Creating Reports from Admin Audit Logs<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
In this post I would love to share with you some of experience that I had with Audit logs in Exchange. You well know about admin audit and mailbox audit logs available in Exchange and their usage so I won't spend too much time discussing them, but rather jump into some examples of retrieving info from admin audit logs.<br />
<br />
So I once was requested about preparing report on who removed user mailboxes and also who added extra permissions to them. The 2 below lines provide code which retrieve when the commands which remove and disable mailboxes and also that assign permissions to the mailbox and also who ran them and when.<br />
<br />
<b>Search-AdminAuditLog -Cmdlets Disable-Mailbox, Remove-Mailbox -StartDate 09/20/2016 -EndDate 09/22/2016 |select ObjectModified,CmdletName,@{N="CmdletParameters";E={$_.CmdletParameters}},Caller,ExternalAccess,Succeeded,RunDate,OriginatingServer,ObjectState |export-csv C:\Reports\Lost-MBX-Report.csv</b><br />
<b><br /></b>
<b><br /></b>
<b>Search-AdminAuditLog -Cmdlets Add-MailboxPermission, Add-ADPermission -StartDate 11/18/2016 -EndDate 11/21/2016 |select ObjectModified,CmdletName,@{N="CmdletParameters";E={$_.CmdletParameters}},Caller,ExternalAccess,Succeeded,RunDate,OriginatingServer,ObjectState |export-csv C:\Reports\AD-Perm-Report.csv</b><br />
<br />
There is also a nicer way to create reports from Admin Audit Logs and <a href="https://blogs.technet.microsoft.com/exchange/2015/06/15/parsing-the-admin-audit-logs-with-powershell/" target="_blank">this article</a> was very helpful as it points to <a href="https://gallery.technet.microsoft.com/scriptcenter/Get-SimpleAuditLogReport-19e9e51a" target="_blank">this script</a> which allows creating quite a nice and readable reports. Imagine you were requested to generate a report on which databases mailboxes have been moved. You will need to execute the code below which will generate reports similar to the ones that are generated by one-liners above:<br />
<br />
<b>$AdmSearch = Search-AdminAuditLog -Cmdlets new-moverequest,New-MigrationBatch</b><br />
<b>$AdmSearch | .\Get-SimpleAuditLogReport.ps1 –agree |Export-csv MigrationCmdlets.csv</b><br />
<div>
<br />
The most valuable information is that the full command is being reported which gives you a good picture what was exactly happening in your environment.<br />
<br /></div>
<div>
Of course you can modify your request for admin log search to anything you like or need. Just use <a href="https://technet.microsoft.com/en-us/library/ff459250(v=exchg.160).aspx" target="_blank">this article</a> for more information.</div>
<div>
<br /></div>
<div>
Enjoy</div>
<br />
<div>
<br /></div>
<div>
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-21740681358697527592017-03-02T10:34:00.003-08:002017-03-02T10:34:35.546-08:00Reinstalling Failed DAG Node from Scratch<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
Just wanted to share with you about another scenario which you may face when you work with DAGs. Sometimes you can have your Exchange servers dead which you need to reinstall . There're 2 options of doing it. The first one is using /RecoverServer parameter while in the other case you will need to scrap all the Exchange server related information from AD. In this post I will cover the second scenario.<br />
<br />
First, you will need to remove all the database copies from the failed server. You will need to run command as below:<br />
<br />
<b>Get-MailboxDatabaseCopyStatus -Server Server01 |foreach {Remove-MailboxDatabaseCopy -Identity $_.Name}</b><br />
<br />
After this server should be removed from DAG. Since server is offline and can't be accessed by the cluster service you will need to use the -ConfigurationOnly parameter and command will be as below:<br />
<br />
<b>Remove-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer Server01 -Confirm:$false -ConfigurationOnly</b><br />
<br />
After this you will need to verify that the server has been indeed removed from DAG by running the below command:<br />
<br />
<b>Get-DatabaseAvailabilityGroup DAG01 |select Name,Servers |fl</b><br />
<br />
After DAG server has been removed it should be evicted from cluster:<br />
<b><br /></b>
<b>Get-ClusterNode Server01 |Remove-ClusterNode -Force</b><br />
<br />
Finally, we will need to clean up AD object for Exchange server. For this purpose ADSIEDIT tool will be needed. You will need to connect ADSIEDIT to Configuration partition and then navigate to the server object, something like below:<br />
<br />
<b>CN=Server01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CONTOSO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com</b><br />
<br />
Delete server object and click Yes for deleting container object. Please don't forget to be extremely careful when using ADSIEDIT, because one wrong mouse click can destroy your Exchange org and you will need to restore AD from backup authoritatively which is not a lot of fun.<br />
<br />
Finally, in this scenario we will need to delete computer object of a dead Exchange server. Merely resetting password for it is not enough. And this is because when Exchange is installed it registers a bunch of Exchange-related SPN records. You can see it as below:<br />
<br />
<b>setspn -l SERVER01</b><br />
<b>Registered ServicePrincipalNames for CN=SERVER01,OU=Servers,DC=contoso,DC=com</b><br />
<b>:</b><br />
<b> MSServerClusterMgmtAPI/SERVER01.contoso.com</b><br />
<b> MSServerClusterMgmtAPI/SERVER01</b><br />
<b> IMAP/SERVER01</b><br />
<b> IMAP/SERVER01.contoso.com</b><br />
<b> IMAP4/SERVER01</b><br />
<b> IMAP4/SERVER01.contoso.com</b><br />
<b> POP/SERVER01</b><br />
<b> POP/SERVER01.contoso.com</b><br />
<b> POP3/SERVER01</b><br />
<b> POP3/SERVER01.contoso.com</b><br />
<b> exchangeRFR/SERVER01</b><br />
<b> exchangeRFR/SERVER01.contoso.com</b><br />
<b> exchangeAB/SERVER01</b><br />
<b> exchangeAB/SERVER01.contoso.com</b><br />
<b> exchangeMDB/SERVER01</b><br />
<b> exchangeMDB/SERVER01.contoso.com</b><br />
<b> SMTP/SERVER01</b><br />
<b> SMTP/SERVER01.contoso.com</b><br />
<b> SmtpSvc/SERVER01</b><br />
<b> SmtpSvc/SERVER01.contoso.com</b><br />
<br />
If brand new computer object is not created Exchange installation may fail or in case of its success, services may fail starting, therefore I highly insist that it is deleted before the OS is re-imaged.<br />
<br />
I hope you will find this post helpful for your dealings with Exchange servers.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-35333040493041441512017-02-08T07:21:00.000-08:002017-02-08T07:21:00.075-08:00RBAC Effective Permissions<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
You are well aware with the effective permissions in the NTFS and also on other objects that are controlled by ACLs (like AD objects or registry).<br />
<br />
Now the same kind of check and report is available for Exchange RBAC. What it does, it checks all the role group membership of an admin account and then provides as an output roles that they were assigned to.<br />
<br />
The below code should do this magic:<br />
<br />
<b>Get-ManagementRoleAssignment -GetEffectiveUsers | Where-Object {$_.EffectiveUserName -eq "Admin"} | Select-Object Role</b><br />
<br />
And it provides code as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-MixNKXjk-5U/WJs3UT3S9BI/AAAAAAAABWQ/o-FAalQ015EmklXHwdO1csJQuSl0b6K5gCLcB/s1600/RBAC_eff01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="45" src="https://4.bp.blogspot.com/-MixNKXjk-5U/WJs3UT3S9BI/AAAAAAAABWQ/o-FAalQ015EmklXHwdO1csJQuSl0b6K5gCLcB/s320/RBAC_eff01.PNG" width="320" /></a></div>
<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-24737962372701970332017-02-06T11:26:00.000-08:002017-02-06T11:26:01.484-08:00A Great and Easy Way to Retrieve Average Message Size<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
Hi folks,<br />
<br />
I have recently been working on one sizing exercise for Exchange 2016. In particular I needed to size servers that will be used for email routing only, no storage of mailboxes whatsoever. As you well know in Exchange 2013 and what's more on 2016 transport is no longer a separate role, however there are no tools available for sizing transport only servers.<br />
<br />
The key parameter for any Exchange calculations is an average message size. Previously Profile Analyzer was a very helpful tool to achieve this purpose. As you know Profile Analyzer no longer works for Exchange 2010 and later. Microsoft has released <a href="https://blogs.technet.microsoft.com/toomasr/2014/06/16/finding-sentreceived-per-user-per-day-and-average-message-size/" target="_blank">this nice tool</a> as a replacement of the Profile Analyzer, however it doesn't work against sites without mailboxes.<br />
<br />
Therefore the only way to get average mail size on the transpport only servers is to use message tracking log. After some searching I have found <a href="https://ficility.net/2013/07/31/exchange-2010-average-message-size-and-similar-reports/" target="_blank">this</a> great article that came to my help.<br />
<br />
So if you have only a single site with the Exchange calculating average size is pretty easy. The following code needs to be executed to achieve this:<br />
<br />
For Exchange 2007 and 2010:<br />
<br />
<b>Get-TransportServer | Get-MessageTrackingLog -resultsize unlimited | measure-object -Property TotalBytes -Maximum –Average</b><br />
<div>
<br /></div>
<div>
For Exchange 2013 and 2016:</div>
<div>
<br /></div>
<div>
<b>Get-TransportService | Get-MessageTrackingLog -resultsize unlimited | measure-object -Property TotalBytes -Maximum –Average</b><br />
<br />
Nice and easy, isn't it.<br />
<br />
Now, let's imagine we will need to calculate average size of all the messages that went trough the server over the course of a business week and that we have more than one AD site. We will need to change our query to all servers within a site, let's call it NEWYORK. the script will look something like this:<br />
<b><br /></b>
<b>$TrpSrv = Get-ExchangeServer |Where-Object {$_.Site -like "*NEWYORK*"} | |Get-TransportService</b><br />
<b><br /></b>
<b>$TrpSrv |foreach {Get-MessageTrackingLog -Server $_.Name -Start "01/09/2017 09:00:00" -End "01/13/2017 17:00:00" -resultsize unlimited | measure-object -Property TotalBytes -Maximum –Average |out-file D:\Scripts\Average.txt -append}</b><br />
<br />
Alternatively you will need to run the same command for each individual server in a site and then use tools like calculator or Excel to calculate average size of the message. In this case the code will be like below:<br />
<br />
<b>Get-TransportService SERVER01 | Get-MessageTrackingLog -Start "01/09/2017 09:00:00" -End "01/13/2017 17:00:00" -resultsize unlimited | measure-object -Property TotalBytes -Maximum –Average |out-file D:\Scripts\Average.txt</b><br />
<br />
I hope you will find this post useful for your sizing adventures.<br />
<br />
Enjoy!<br />
<br /></div>
<div>
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-74329724362052604352017-01-20T08:12:00.001-08:002017-01-20T08:12:10.347-08:00PowerShell Module to Retrieve ACLs from Different Sources<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
In <a href="http://farkhadm.blogspot.co.uk/2016/05/great-script-for-managing-ntfs.html" target="_blank">this post</a> I have shared with you about PowerShell module that can be used to manage and report NTFS permissions on disk drives and files and folders. However I was also looking for a nice way to report Active Directory ACLs and ACEs by using PowerShell. The Get-Acl cmdlet wouldn't suffice as it would report extended permissions on AD as ExtendedRight without any clear details. <a href="https://gallery.technet.microsoft.com/scriptcenter/PowerShellAccessControl-d3be7b83#content" target="_blank">Here</a> you can download PowerShell module that allows you to manage ACLs and ACEs not only on file system but also on printers, registry and most importantly AD.<br />
<br />
Just as NTFS module this module needs to be installed to the server or computer on which you are running it. You will need to unzip the downloaded files and copy module and the related files to <b>%Windir%\System32\WindowsPowerShell\v1.0\Modules</b>. Before this you will need to create a folder named <b>PowerShellAccessControl</b>. The below code should do installation magic.<br />
<br />
<b>New-Item "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PowerShellAccessControl" -Type Directory</b><br />
<b>Copy-Item "C:\Scripts\PowerShellAccessControl\*" "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PowerShellAccessControl"</b><br />
<br />
<br />
You can read more about the cmdlets in the module in the link published below as they are described in the article. Before running any cmdlet you will first need to import the module into your PowerShell session:<br />
<br />
<b>Import-Module PowerShellAccessControl</b><br />
<br />
There're a bunch of the cmdlets in module, I will show you just couple of the samples that you needed and you will thread your own way.<br />
<br />
This command will get AD permission from<br />
<br />
<b>Get-ADObject "CN=SERVER01,OU=Servers,DC=CONTOSO,DC=COM"| Get-AccessControlEntry</b><br />
<br />
(you can also use <b>Get-AdUser</b>, <b>Get-ADGroup</b> and other cmdlets from the Active Directory PowerShell module to get AD input object)<br />
<br />
Finally, another sample below retrieves permissions for the same object for a particular user or group:<br />
<br />
<b>Get-ADObject "CN=SERVER01,OU=Servers,DC=CONTOSO,DC=COM" |Get-AccessControlEntry |Where-Object {$_.Principal -eq "Contoso\ContosoAdmins"}</b><br />
<br />
I will let you explore this module further by yourselves and I hope you will find it to be useful.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-51761155079727966802017-01-16T04:29:00.003-08:002017-01-16T04:29:30.473-08:00Some Additions to My Old ActiveSync Reporting Post<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
Couple of years ago I have shared with you <a href="http://farkhadm.blogspot.co.uk/2014/04/activesync-in-large-environment.html" target="_blank">this post</a> on the code that can be used for reporting of the ActiveSync devices. It still remains valid. However, I'd love to post here some amendments that may be useful for you.<br />
<br />
Firstly, Microsoft has introduced in Exchange 2013 the cmdlet Get-MobileDeviceStatistics which at one point may replace Get-ActiveSyncDeviceStatistics and I won't be surprised that the latter one will be deprecated in one of the next builds or major versions. Therefore I have updated my code using it. And secondly I also wanted to report some more information into my report. I wanted to be able to report user agent and also when the device has successfully synced last time. Therefore parameters LastSuccessSync and DeviceUserAgent have been added to the code. The updated code looks like as below, and I would recommend using it with Exchange 2013 and 2016.<br />
<br />
<b>$EasUser=Get-CASMailbox -ResultSize Unlimited |Where-Object {$_.HasActiveSyncDevicePartnership-eq 'True'}</b><br />
<b>$EasUser | foreach {Get-MobileDeviceStatistics -Mailbox $_.Name | select identity,LastSuccessSync,devicetype,deviceid,DeviceUserAgent,isremotewipesupported,LastSuccessSync} |Export-Csv D:\MessagingMetricsReports\ActiveSyncUsageReport.csv</b><br />
<br />
Again, you can add as many parameters as you want to see in your final report.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-5441119024529910292017-01-13T10:31:00.004-08:002017-01-13T10:31:55.116-08:00Retrieve TPM Module Version Using PowerShell<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
I would love to share with you two quick ways to retrieve version of TPM module. What is TPM module and how it helps in BitLocker encryption you can find <a href="https://technet.microsoft.com/en-gb/library/cc749022(v=ws.10).aspx" target="_blank">here</a>.<br />
<div>
<br /></div>
I found it thanks to <a href="http://en.community.dell.com/techcenter/b/techcenter/archive/2015/12/09/retrieve-trusted-platform-module-tpm-version-information-using-powershell" target="_blank">this article</a> from Dell. I have adapted this command to retrieve the hostname and version of TPM module installed there. My code looks like below:<br />
<br />
<b>Get-WMIObject –class Win32_Tpm –Namespace root\cimv2\Security\MicrosoftTpm |select PsComputerName,SpecVersion</b><br />
<br />
<br />
This will produce output as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-bJMxuoANitg/WHkTn0itKRI/AAAAAAAABVk/wRCs05WkMOwtZLtk_hHZTY0HBaZVKjVqQCLcB/s1600/TPM01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="33" src="https://3.bp.blogspot.com/-bJMxuoANitg/WHkTn0itKRI/AAAAAAAABVk/wRCs05WkMOwtZLtk_hHZTY0HBaZVKjVqQCLcB/s320/TPM01.PNG" width="320" /></a></div>
<br />
The <b>SpecVersion </b>corresponds to the version of the TPM module. Above is the output for TPM 2.0<br />
<br />
<br />
Finally, there is a nice way to report it for more than one server remotely. This can be achieved by using TPM management module which has been published <a href="https://gallery.technet.microsoft.com/scriptcenter/Script-to-list-TPM-chip-7e651c27" target="_blank">here</a> in TechNet gallery. ZIP file can be downloaded from the same link and exported. After which module needs to be imported into PS session. Since in my case I'm trying to report information on TPM module installed on Exchange servers I imported it to EMS session.<br />
<br />
The command<b> Get-OSCTPMChip</b> is needed to retrieve information from the computer and can be run against remote computers. For it to work successfully you will need to create variable for credentials.<br />
<br />
I have composed the below code to connect to all Exchange 2016 servers in the environment and retrieve server host name and TPM module version:<br />
<br />
<b>$Cred = Get-Credential</b><br />
<b>Import-Module 'C:\Scripts\GetTPMChipsStatus (PowerShell)\GetTPMChipsStatus.psm1'</b><br />
<b>$Exch2016 = Get-ExchangeServer | where-object {$_.AdminDisplayVersion -like "*Version 15.1*"}</b><br />
<b>$Exch2016 |foreach {Get-OSCTPMChip -ComputerName $_.Name -Credential $Cred} |select ComputerName,SpecVersion |Export-Csv C:\Scripts\TPMExchangeReport.csv</b><br />
<div>
<br /></div>
I hope you will find it useful.<br />
<br />
Enjoy!<br />
<br />
<br />
<div>
<br /></div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-45343197264139631102017-01-12T04:28:00.000-08:002017-01-12T04:28:08.732-08:00Sending Messages as Scheduled Task<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
I would love to share with you about my recent adventure on configuring scheduled task for running some Exchange-related scheduled tasks using PowerShell. To avoid using excessive permissions for an account that will run the scheduled task I created user account in AD with the default group membership (Domain Users). This account has been granted "Logon as batch job" rights on a server where the scheduled task will run. The script included a line to send results of the script execution to an admin's email address, something like below:<br />
<b><br /></b>
<b>Send-MailMessage -from sender@contoso.com -to recipient@contoso.com -subject "Scheduled Task Report" -body ($bb | out-string) -smtpServer 'server01.contoso.com' -bodyashtml</b><br />
<br />
However, emails wouldn't arrive. There was nothing in the task to indicate failure of it as it ran smootly. So the following line was added to the beginning of the script:<br />
<br />
<b>Start-Transcript -Path C:\Scripts\executionTranscript.txt</b><br />
<br />
And at the end of the script I appended:<br />
<br />
<b>Stop-Transcript</b><br />
<br />
When checking execution transcript I would see the error as below:<br />
<br />
<b>Send-MailMessage : Mailbox unavailable. The server response was: 5.7.1 Client does not have permissions to send as</b><br />
<b>this sender</b><br />
<b>At D:\ML\Scripts\QueueStatus.ps1:16 char:1</b><br />
<b>+ Send-MailMessage -from sender@contoso.com -to recipient@contoso.com ...</b><br />
<b>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</b><br />
<b> + CategoryInfo : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpExcept</b><br />
<b> ion</b><br />
<b> + FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage</b><br />
<br />
What it says that service account can send as <b>sender@contoso.com</b> (of course there should be your sender address here). To resolve this issue scheduled task will need to be reconfigured to run as <b>sender@contoso.com </b>with granting rights as mentioned above. Alternatively, service account can be mail or mailbox enabled (I would recommend the former) and script updated to send email as service account.<br />
<br />
You will need to run the below code to mail-enable the service account:<br />
<br />
<b>Enable-MailUser -Identity "CONTOSO\serviceaccount" -PrimarySMTPAddress "serviceaccount@contoso.com" -ExternalEmailAddress "serviceaccount@contoso.com"</b><br />
<br />
Then you will need to reconfigure your code to something as below:<br />
<br />
<b>Send-MailMessage -from serviceaccount@contoso.com -to recipient@contoso.com -subject "Scheduled Task Report" -body ($bb | out-string) -smtpServer 'server01.contoso.com' -bodyashtml</b><br />
<br />
<br />
I hope you will find this useful when troubleshooting issue as this one.<br />
<br />
Enjoy!<br />
<div>
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-79881622759698870172017-01-12T03:18:00.001-08:002017-01-12T03:18:19.232-08:00Resetting IDRAC on Dell Servers<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
If you are using Dell R720 or R730 you may have encountered IDRAC, a Java-based tool that allows us to remotely connect to server and manage it from console without a need to go to a datacenter and play with KVM there.<br />
<br />
However this is what I once encountered. I saw that the Volume Console Preview shows me black screen while trying to connect to server remotely. In the Virtual Console Preview on the IDRAC page instead of server login page I would see black screen:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-9JIUTT3xrKg/WHZoJMysLQI/AAAAAAAABUs/oKQcvJPTm_o-uUUpzkul3eJiFcEovO6FgCLcB/s1600/IDRAC03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="185" src="https://3.bp.blogspot.com/-9JIUTT3xrKg/WHZoJMysLQI/AAAAAAAABUs/oKQcvJPTm_o-uUUpzkul3eJiFcEovO6FgCLcB/s320/IDRAC03.PNG" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
When trying to launch remote console I would see the error as below:</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-tVfVSQSxbks/WHdl48XCCmI/AAAAAAAABVQ/-GpPUM0pdjQcI6Mv7prT730bbVUtKa2bQCLcB/s1600/IDRAC05.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="179" src="https://3.bp.blogspot.com/-tVfVSQSxbks/WHdl48XCCmI/AAAAAAAABVQ/-GpPUM0pdjQcI6Mv7prT730bbVUtKa2bQCLcB/s320/IDRAC05.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br />
To resolve this, you will need to launch Command Line (not PowerShell!) as admin on your server and run the below command:<br />
<b><br /></b>
<b>racadm racreset soft</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-2E1VjSBp3ok/WHZl5ew0AuI/AAAAAAAABUg/42lkJfpClzw1x4x0GzMijjC0WxaOKMbCACLcB/s1600/IDRAC01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="72" src="https://3.bp.blogspot.com/-2E1VjSBp3ok/WHZl5ew0AuI/AAAAAAAABUg/42lkJfpClzw1x4x0GzMijjC0WxaOKMbCACLcB/s320/IDRAC01.PNG" width="320" /></a></div>
<br />
Give it about 5 Minutes to reset and then login to IDRAC again and in the virtual console section you will see the following in the Virtual Console Preview section:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-VJxyBrvBulY/WHZpxrWT9WI/AAAAAAAABVA/6SQkM25JQfo3j9818o9UnzXqDBW2MUmHgCLcB/s1600/IDRAC02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="208" src="https://4.bp.blogspot.com/-VJxyBrvBulY/WHZpxrWT9WI/AAAAAAAABVA/6SQkM25JQfo3j9818o9UnzXqDBW2MUmHgCLcB/s320/IDRAC02.PNG" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
This indicates that the command has done the magic and you now can click Launch to connect to your server's console remotely.<br />
<br />
I hope you will find this helpful.<br />
<br />
Enjoy!</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-20053923799372840762017-01-11T08:50:00.002-08:002017-01-11T08:50:41.648-08:00Decommissioning Exchange 2010 and Later Mailbox Servers<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
As Exchange 2016 is around and Exchange 2013 has been around even longer many of you are dealing with decommissioning of your Exchange 2010 servers. Another reason for decommissioning 2010 servers is moving to the cloud. Surely this is one of the greatest versions of Exchange and will be greatly missed.<br />
<br />
In this post I will focus on decommissioning of Mailbox servers, especially DAG members. You can read <a href="http://exchangeserverpro.com/exchange-server-2010-2013-migration-removing-legacy-servers/" target="_blank">this article</a> for more details on decommissioning of Exchange 2010 servers and consideration on every role.<br />
<br />
This post assumes that all mailboxes have been moved off servers, otherwise we won't be able to decommission mailbox databases.<br />
<br />
First we need to remove every mailbox database copy on the server. As a lazy man I prefer to do it using one code line (two if possible). One liner didn't work for me:<br />
<br />
<b>Get-MailboxDatabaseCopyStatus -Server SERVER01 |foreach {Remove-MailboxDatabaseCopy -Identity $_.Name -Confirm:$false}</b><br />
<br />
I got the error as below:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-TM1DVau8rUk/WHZbtrLEKXI/AAAAAAAABUA/rIWC23ocXAE7YV8-2sspILQp6_-gI6lnACLcB/s1600/DAGDecom01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="48" src="https://4.bp.blogspot.com/-TM1DVau8rUk/WHZbtrLEKXI/AAAAAAAABUA/rIWC23ocXAE7YV8-2sspILQp6_-gI6lnACLcB/s320/DAGDecom01.PNG" width="320" /></a></div>
<br />
So I ended up feeding database copies to the variable <b>$DBCop</b>, After this I ran <b>Remove-MailboxDatabaseCopy</b> against every DB in the <b>$DBCop</b> variable. The code looks as below:<br />
<br />
<b>$DBCop = Get-MailboxDatabaseCopyStatus -Server SERVER01</b><br />
<b>$DBCop |foreach {Remove-MailboxDatabaseCopy -Identity $_.Name -Confirm:$false}</b><br />
<br />
After mailbox database copies are removed we will need to remove mailbox databases themselves:<br />
<b><br /></b>
<b>$DB = Get-MailboxDatabase -Server SERVER01</b><br />
<b>$DB |foreach {Remove-MailboxDatabase -Identity $_.Name -Confirm:$false}</b><br />
<br />
You are not mistaken to see Get-MailboxDatabase command with -Server parameter. Though in Exchange 2010 and onward DBs are managed globally, still this command works and retrieves all mailbox DB copies stored on a server, This is ideal for limiting output of mailbox databases to a server which we decommissioning. And I don't want PowerShell to complain me about buffer so I create here $DB variable almost immidiately.<br />
<br />
After this we will need to remove every DAG member from DAG. Firstly, we will need to disable DAC mode from DAG:<br />
<br />
<b>Set-DatabaseAvailabilityGroup DAG01 -DatacenterActivationMode Off</b><br />
<br />
After this we will need to remove each DAG member by runing this command:<br />
<br />
<b>Remove-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer SERVER01 -Confirm:$false</b><br />
<br />
After all of mailbox servers are removed from DAG you can kill DAG object in the AD as well:<br />
<br />
<b>Remove-DatabaseAvailabilityGroup -Identity DAG01 -Confirm:$false</b><br />
<br />
Remove CAS array (the only ugly thing about Exchange 2010) object from the AD:<br />
<br />
<b>Remove-ClientAccessArray outlook.contoso.com -Confirm:$false</b><br />
<br />
Finally, you will need to uninstall Exchange binaries. For Exchange 2010 this command does the magic:<br />
<br />
<b>setup.com /m:Uninstall</b><br />
<b><br /></b>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-bdva3AOoXaw/WHZiUAwLBKI/AAAAAAAABUU/VpSptBAEresRiNFvVVXFr6JZ3RlIOiYJwCLcB/s1600/DAGDecom02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="221" src="https://1.bp.blogspot.com/-bdva3AOoXaw/WHZiUAwLBKI/AAAAAAAABUU/VpSptBAEresRiNFvVVXFr6JZ3RlIOiYJwCLcB/s320/DAGDecom02.PNG" width="320" /></a></div>
<b><br /></b>
<br />
For Exchange 2013 and later you will need to run<br />
<br />
<b>setup.exe /m:Uninstall /IAcceptExchangeServerLicenseTerms</b><br />
<br />
Enjoy!<br />
<div>
<br /></div>
</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-21953039006943545762017-01-10T09:31:00.000-08:002017-01-10T09:31:00.827-08:00Changing Your AD Password Via RDP<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
Many of you may already know it and therefore please feel free to ignore this little post. However, I have recently learned a nice trick on how to change your AD password via RDP screen. It is especially useful for engineers and admins who admin their Windows servers via RDP Manager or a single RDP conenction (aka MSTSC command).<br />
<br />
You will need to run the following command: osk<br />
<br />
It will display on-screen keyboard. On your normal keyboard you will need to hit Ctrl+Alt while on the on-screen keyboard you will need to click on Delete.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-QcmCwHDBXTI/WHUZxXZ-P1I/AAAAAAAABTk/P1Ew8OY4dgkQxHEhBdWc2fJwuYgIIi0iQCLcB/s1600/PWD-RDP01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="104" src="https://4.bp.blogspot.com/-QcmCwHDBXTI/WHUZxXZ-P1I/AAAAAAAABTk/P1Ew8OY4dgkQxHEhBdWc2fJwuYgIIi0iQCLcB/s320/PWD-RDP01.PNG" width="320" /></a></div>
<br />
<br />
That will display password change screen. An you know yourself what to do further.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-deUjEQa0VXU/WHUaE_XENNI/AAAAAAAABTo/Hes5v2OUR54vD9qu3EjNBEuIdWjzY-1vgCEw/s1600/PWD-RDP02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="256" src="https://1.bp.blogspot.com/-deUjEQa0VXU/WHUaE_XENNI/AAAAAAAABTo/Hes5v2OUR54vD9qu3EjNBEuIdWjzY-1vgCEw/s320/PWD-RDP02.PNG" width="320" /></a></div>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-xDmNNc9f7jg/WHUaE65pB6I/AAAAAAAABTs/9CQ_r815cIssYv71n3vHawAy2c8fxCXCwCLcB/s1600/PWD-RDP03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="174" src="https://2.bp.blogspot.com/-xDmNNc9f7jg/WHUaE65pB6I/AAAAAAAABTs/9CQ_r815cIssYv71n3vHawAy2c8fxCXCwCLcB/s320/PWD-RDP03.PNG" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
Enjoy!</div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-1101079934070416822017-01-10T03:42:00.001-08:002017-01-10T03:48:18.245-08:00Extracting AD Group Members Using PowerShell<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="MsoNormal">
Hi guys,<br />
<br />
Imagine you know the name of the distribution list of the AD group which is not mail-enabled and you will need to extract members of it. The below code should come to your help. I personally ran it from the Exchange Management Shell and had AD PowerShell module loaded (which is needed on any machine running Exchange tools anyway. The first line extracts distinguished name of the group into a variable, while the second one is extracting group members (in my case attributes like DistinguishedName and samAccountName (you can change output attributes just as you need). These attributes are dropped into the CSV file.</div>
<div class="MsoNormal">
<b><br /></b></div>
<div class="MsoNormal">
<b>$Grp = (Get-Group MyGroupName).DistinguishedName<o:p></o:p></b></div>
<b><br /></b>
<br />
<div class="MsoNormal">
<b>Get-ADGroupMember $Grp |select
DistinguishedName,SamAccountName |Export-Csv c:\Scripts\GrpMbr.csv</b><o:p></o:p><br />
<br />
Enjoy!</div>
</div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0tag:blogger.com,1999:blog-3174986391557883428.post-81182599811202893322017-01-09T11:38:00.003-08:002017-01-09T11:38:14.850-08:00Capturing Exchange Components Logs<div dir="ltr" style="text-align: left;" trbidi="on">
Hi folks,<br />
<br />
There are moments in our lives when we need to perform some troubleshooting of our Exchange environment. You can increase loggi<br />
<br />
You can read more about logging for Exchange components in <a href="https://technet.microsoft.com/en-us/library/dd335139(v=exchg.141).aspx" target="_blank">this article</a><br />
<br />
For components list and how it has changed in Exchange 2013 you can refer <a href="https://justaucguy.wordpress.com/2013/05/21/exchange-2013-diagnostic-logging/" target="_blank">here</a><br />
<br />
If you want to retrieve list of all Exchange components you can run this command:<br />
<br />
<b>Get-EventLogLevel -Identity "MSExchange*" |sort Identity</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-eD2H_H7g93Q/WD1nXUgrBdI/AAAAAAAABR8/s7CfgxJSEQEmxc3uexnbHlgO9tSZ2ufIACLcB/s1600/Event01.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="196" src="https://2.bp.blogspot.com/-eD2H_H7g93Q/WD1nXUgrBdI/AAAAAAAABR8/s7CfgxJSEQEmxc3uexnbHlgO9tSZ2ufIACLcB/s320/Event01.PNG" width="320" /></a></div>
<br />
<br />
In my case I needed to perform troubleshooting of EWS so to check its logging level you will need to run the following command:<br />
<br />
<b>Get-EventLogLevel -Identity "MSExchange Web Services\Core"</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-TRCterMDn-w/WD1ne_rHlgI/AAAAAAAABSA/DhMmpkpca30imAYvM-bwSuwS1wZ1Uo_qACLcB/s1600/Event02.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="29" src="https://1.bp.blogspot.com/-TRCterMDn-w/WD1ne_rHlgI/AAAAAAAABSA/DhMmpkpca30imAYvM-bwSuwS1wZ1Uo_qACLcB/s320/Event02.PNG" width="320" /></a></div>
<br />
<br />
Depending on the logging detail level required you will need to run Set-EventLogLevel command and specify logging level depending on the logging details required. The possible logging levels that you can set are: 0 (Lowest), 1 (Low), 3 (Medium), 5 (High), and 7 (Expert). In my case I needed all details so I ran the following command:<br />
<br />
<b>Set-EventLogLevel -Identity "MSExchange Web Services\Core" -Level 7</b><br />
<br />
After completing your troubleshooting activities you will need immidiately revert setting back to the default (Lowest or 0 in our case)<br />
<br />
<b>Set-EventLogLevel -Identity "MSExchange Web Services\Core" -Level 0</b><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-I4-tOIz0rbQ/WD1mb8gYXMI/AAAAAAAABR0/zAbUEzji7IIQa8dIsuUSTWb83X0zNL_5gCLcB/s1600/Event03.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="63" src="https://3.bp.blogspot.com/-I4-tOIz0rbQ/WD1mb8gYXMI/AAAAAAAABR0/zAbUEzji7IIQa8dIsuUSTWb83X0zNL_5gCLcB/s320/Event03.PNG" width="320" /></a></div>
<br />
<br />
Enjoy!<br />
<br />
<br />
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/05554925514239633262noreply@blogger.com0