How to free up the conference room calendar from terminated employees’ meetings? Here are the base line PowerShell commands for you to write a script.
To check if any meetings booked by employees in any of the conference rooms who no longer works in your office:
Get-Mailbox -RecipientTypeDetails RoomMailbox | Search-Mailbox -Searchquery "kind:meetings from:<DisplayName>" -EstimateResultOnly | Select Identity,ResultItemsCount | ft -AutoSize
Note: Replace <DisplayName> in the command above with terminated user’s display name.
To Delete the meetings booked by the terminated employees:
Get-Mailbox -RecipientTypeDetails RoomMailbox | Search-Mailbox -Searchquery "kind:meetings from:<DisplayName>" -DeleteContent -Force
Now the script to purge all meeting booked by terminated users.
Note: Change the SEARCHBASE options according to your AD environment. If you remove -SEARCHBASE option from Search-ADAccount command in the script, it will list all disabled accounts from entire domain.
* * * * * Purge Meetings Booked by Terminated Users * * * * *
Delete meetings from conference rooms booked by employees terminated last 7 days.
Written by: Anand, the Awesome
Created on: 12/21/2018
$dt = date_time
$logfile = ".\PurgeMeetings-of-termed-users" + $dt + ".log"
Start-Transcript -Path $logfile
#Get the terminiated user list
REPLACE THE SEARCH BASE - BASED ON YOUR AD ENVIRONMENT HERE BELOW
$TermedUsers = Search-ADAccount -AccountDisabled -SearchBase 'OU=Users,DC=corp,DC=company,DC=com'
#List all conference rooms
$ConferenceRooms = Get-Mailbox -RecipientTypeDetails RoomMailbox
foreach($TermedUser in $TermedUsers)
Write-Host "Processing $($Termeduser.Name).."
#Delete tehe meeting booked by terminated user
$ConferenceRooms | Search-Mailbox -Searchquery "kind:meetings from:$($TermedUser.Name)" -DeleteContent -Confirm:$false -Force
# * * * End of the Script * * *
Are you getting this error when running Get-MailboxFolderPermission?
PS E:\> Get-MailboxFolderPermission firstname.lastname@example.org:\calendar
The security principal specified is already on the permission set.
+ CategoryInfo : NotSpecified: (:) [Get-MailboxFolderPermission], CorruptDataException
+ FullyQualifiedErrorId : [Server=ZN1UR12MB0288,RequestId=b4f155be-a238-4a98-8b3f-f3d9258e22d2,TimeStamp=6/19/2018 10:10:41 PM] [FailureCategory=Cmdlet-CorruptDataException] F8D77EE2,Microsoft.Exchange.Management.StoreTasks.GetMailboxFolderPermission
+ PSComputerName : outlook.office365.com
The error message seems cryptic, right? But it is not. It means there is a DUPLICATE entry for the same user (security principal) is in the permission set for the calendar folder permissions.
So how do we fix it?
The ONLY way is to use Outlook to remove the duplicate entry.
Yes, that means
- give yourself full access permission to the mailbox,
- create an Outlook profile (or just a calendar),
- go to Calendar, right click and go to properties, & then Permissions
- remove the duplicate user entry
As Exchange Administrator, if you want to find out any user’s mailbox size information by folder and number of items in each folder, you can to the right place. Here is the PowerShell Command to list the folders, number of items in the folder and size of the folders.
Replace the email@example.com with user’s primarySMTPAddress.
(Get-MailboxFolderStatistics -Identity Username@Domain.com) |sort itemsinfolder -descending |ft folderpath,itemsinfolder,FolderSize
The results will look like this:
FolderPath ItemsInFolder FolderSize
---------- ------------- ----------
/Inbox/Important_email 1907851 2.661 GB (2,857,213,378 bytes)
/Junk E-Mail 461173 1.801 GB (1,933,977,887 bytes)
/Inbox/S - Archived/KIRA 15085 539.8 MB (566,024,075 bytes)
/Deleted Items 12202 418.3 MB (438,663,132 bytes)
/Recoverable Items 9109 56.48 MB (59,219,680 bytes)
/Calendar 3276 127.2 MB (133,343,630 bytes)
/Inbox/1 - Archived/Munchkins 2558 48.49 MB (50,848,487 bytes)
/Sent Items 1355 45.74 MB (47,961,704 bytes)
/Inbox/0 - YOps Mist 1339 389.1 MB (408,029,942 bytes)
/Inbox/1 - Archive 1147 118 MB (123,761,904 bytes)
/Inbox/5 - Alerts 929 33.92 MB (35,571,617 bytes)
/Inbox/1 - Archive2 920 142.1 MB (149,002,073 bytes)
Are you getting this following error in Exchange Console or Shell?
Connecting to remote server ExchServer.company.com failed with the following error message : The WS-Management service cannot process the request. The system load quota of 1000 requests per 2 seconds has been exceeded. Send future requests at a slower rate or raise the system quota.
It means, IIS/PowerShell App Pool is over loaded.
I saw on other sites on more drastic solution like running IISReset on Admin privileged command prompt. That would affect entire Exchange client features.
Logon to the specfic Exchange server on the error message
Open IIS Management Console and navigate to IIS Application Pools
Restart PowerShell App Pools
Exchange 2010 or Exchange 2010 Service Pack fails on Exchange Analyzer on checking pre-requisites. This should be easy to resolve. If you are seeing this same error after reboot, there must be orphaned registry values left from previous setup files. Check and fix the following two registry keys and setup should continue normally.
To remove an orphaned UpdateExeVolatile registry key value
Open a registry editor, such as Regedit.exe or Regedt32.exe.
Navigate to HKLM\SOFTWARE\Microsoft\Updates\
In the right navigation pane, double-click the UpdateExeVolatile key.
Configure the key with a value of 0
Close Registry Editor.
To delete the orphaned PendingFileRenameOperations registry key
Open a registry editor, such as Regedit.exe or Regedt32.exe.
Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\
In the right navigation pane, right-click the PendingFileRenameOperations key and select Delete.
Close Registry Editor.
I found this info at http://technet.microsoft.com/en-us/library/cc164360(v=EXCHG.80).aspx.
You already have an Active Directory account and you want to create an Exchange Mailbox. You clicked New Mailbox command from Action Pane, selected the account and clicked New. Now you get this very “informational message”, Exchange refused to create Mailbox because it “could not convert property WindowsEmailAddress to type SmtpAddress.”
Do Not Panic. Oh! you already panicked and searched Internet and found this blog. Alright then, let’s interpret this error message and fix this issue.
The error message is saying the existing Active Directory account is set to mail property with invalid e-mail address. Exchange is saying the existing e-mail address from AD account is not SmtpAddress type which supposed to be Name@domain.com.
Solution: Open the AD account properties in Active Directory Users and Computers console and check E-Mail property in General tab. Remove the value from E-Mail property and try creating the mailbox again.
If you end up with message Action ‘Disable’ could not be performed on object ‘name’ along with “Active directory response: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0”, there is an explanation and solution for this issue.
Is the active directory account for the Mailbox disabled? If yes, Mailbox is probably lost permission on SELF account. I would recommend enable the Active Directory account to disable or delete the mailbox.
Now the real explanation would be the account Exchange Trusted Subsystem don’t have permissions for the account to remove the Exchange attributes. It may be due the permissions are NOT inheriting to the user account.
The solution is to do the two things.
1. Give Exchange Trusted Subsystem account Full Control over the User account
- Open Active Directory Users and Computers console
- Click View –> Advanced Features
- Find the User account and double click to open the properties.
- Click on Security Tab
- Select Exchange Trusted Sub System and check the box for Full control permission.
2. Enable permission In-heritance
- On the Security tab on user account properties (see above picture), click on Advanced button
- Check the box for
Wait for Active Directory Replication to happen or trigger manual replication between servers and sites. Try disable or delete operation again on the same mailbox.
If that works for you, reply “Yay!” for me here.
This issue is interesting. Some Windows 7 computers refused to connect to Exchange server. User is able to use Outlook Web App to check emails.
After some research, I found LmCombatibilityLevel registry key (which is explained here: http://technet.microsoft.com/en-us/library/cc960646.aspx). By default it supposed to set to 0.
The value zero means,
Clients use LM and NTLM authentication, but they never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
The key is highlighted above. I believe Exchange 2010 and Windows 2008 R2 domain use NTLMv2 by default. But how come the default settings is ZERO. The setting 1 makes lots of sense. And changing to 1 resolved my issue. Here is how you resolve the issue if you are facing the same issue.
- Open Registry Editor by running Regedit.exe.
- Browse to HKEY_LOCAL_MACHINE >>> SYSTEM >>> CurrentControlSet >>> Control >>> Lsa
- Right click on the right side window, Click New > DWORD (32-bit) Value, type the name LmCompatibilityLevel and press Enter.
- Double click on LmCompatibilityLevel key and add the value as 1.Click OK.
- Close Registry Editor and Reboot the computer.
Your Outlook should be working now. If not you are facing some other issue.
This wonderful heavenly Outlook message brings loads of joy to the user when he/she sees it. You could create a new Outlook profile, but there is a better way.
Click Windows Key+R to open Run dialog and type the following.
It should resolve the issue by recreating the folders. If Yes, so say YES!!!
Changing the primary SMTP e-mail address in Exchange system is as easy as select a e-mail address & set as reply in E-Mail Addresses tab in Mailbox properties. Well, now it’s greyed out. Baffled? Don’t be.
Answer: Uncheck the option for Automatically update e-mail addresses based on e-mail address policy. That’s it. E-mail address policy is being applied to this mailbox, that’s why you can’t change the default settings.