Christos Polydorou

A common issue that troubles both helpdesk teams and administrators is account locks on Active Directory. By default, when a number of failed authentication attempts is reached, the account is locked for a time period. Since there may services that depend on Active Directory, the user might have tried to login to a workstation, a web application or even forgotten to update the password on a mobile device connected to Exchange. In order to troubleshoot the issue, the first step is to find the computer that the failed authentication attempt was performed against. Knowing the computer will most probably lead to the service and in turn the solution of the problem. Having a user account that is currently locked is not a big deal since only a user is affected. When it comes to service accounts that my perform various tasks, thing are getting more serious. The newest version of my Active Directory module for Powershell ( version 1.2.1 ) includes an new function called "Get-ActiveDi

Following the recently published article on reading xml configuration files using PowerShell, we are going to enrich the configuration file and create custom PowerShell objects. This time the configuration file is a bit different, we have multiple "Company" nodes that have inline properties. <configuration> <Company Name= "Company1" > <Group DN= "CN=Group1,OU=Groups,OU=Company1,DC=lab,DC=local" Name= "Group1" /> <OU DN= "OU=Users,OU=Company1,DC=lab,DC=local" /> </Company> <Company Name= "Company2" > <Group DN= "CN=Group2,OU=Groups,OU=Company2,DC=lab,DC=local" Name= "Group2" /> <OU DN= "OU=Users,OU=Company2,DC=lab,DC=local" /> </Company> </configuration> There aren't many changes in the script, just in the variable that holds the entire configuration. Param

Although there are many tools that are very helpful when it comes to automating tasks, a simple script in most cases may be the fastest and most simple solution. Instead of hardcoding the configuration options for the script within it, wouldn't it be more clean and elegant if you used a configuration file? As an example I'm going to use the simple task of adding users to a group in Active Directory. The purpose of the script is to add users from a specific OU to a specific distribution group after applying filtering based on the SamAccountName attribute. Since we want to be able to use the same script for different OU and group combination we have to create some kind of configuration file and what would be better that xml! With the following xml we are specifying the name of the company, the distinguished name of the group and the OU and two exclusions. <configuration> <Company> Company1 </Company> <GroupDN> CN=Gr

Exchange Application Impersonation. More and more applications are starting to take advantage of this great feature of Exchange and you as the Exchange administrator have to assign the role. Wouldn't be nice if you had a way to verify that the role has been successfully assigned? The newest version of my Exchange module - that is 2.2.1 - includes the "Test-ExchangeImpersonation" cmdlet which will allow you to test the application impersonation role assignment. Before diving into the examples, a few words on the impersonation. Impersonation is used when we need to give access to an account in order to perform actions on mailboxes. When the application impersonation role is assigned to a principal, that principal can act on the mailbox and perform many actions such as reading and sending mail, managing calendar and contacts, etc. On the examples below, the principal with the impersonation permission is test.impersonation and the mailbox that is going to be impersonat

A new version of my Exchange module has been published on the PowerShell Gallery. This new version contains cmdlets to Get, Enable and Disable the mailbox auto mapping feature for a user on a shared mailbox. A few words about auto mapping. When an exchange administrator grants permissions on a mailbox (doesn't matter if the mailbox is a user mailbox or a shared mailbox) to another recipient, the shared mailbox will be automatically added to the users Outlook client. This is the mailbox auto mapping feature which is also enabled by default. When granting permission on a user you can disable the auto mapping by using the "-AutoMapping:$false" switch with the "Add-MailboxPermission" cmdlet, but what if the permission is already granted? Of course you could remove and re-add the permission with the switch I just mentioned but let's see a more elegant way of configuring it! When a user is granted permission on another mailbox - let's call it shared mail