Test Layout

A virus has recently been making the rounds that propagates by renaming folders and storing an executable file in a Recycle Bin folder. Just today we saw this on some shared folders. Here is a link with more info about the virus: http://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/worm_zlader.b So, we can identify that someone is infected by finding the $Recycle.Bin folders in the shares. But we need to track down where this came from. To do that we want to see the owner of the $Recycle.Bin folder because that is the person that created it. You can't get the owner of the $Recycle.Bin folder by using Windows Explorer because Explorer treats this as a special folder type and limits what you can see. However, you can find the owner by using Get-ACL in PowerShell. On a large file server with many shares, it's useful to scan the whole server to verify the extent of the infection. The script below starts in the current directory, finds all of the Recycle.Bin folders, displ

So, this was a thing back in the middle of June and I missed it at the time. Looking back there are a few articles about it, but I just ran into this with a client (happily, before the update was applied) and I think it's worth raising awareness of. In some security updates for Vista and later released on June 14, 2016 the process for Group Policy object (GPO) downloading has been changed. To make the download process more secure, the computer account is now responsible for downloading all GPOs. In the past, the user account could download the GPOs also. The result of this change is that any computer that is downloading GPOs needs to have Read access to the GPO. The computer accounts do not need Apply permission, only Read is required. By default the Authenticated Users group has Read and Apply permission for all GPOs. The Authenticated Users group includes all users and all computer accounts. So, if you haven't changed this, then you'll have no issues when these security u

Those that are really paranoid about security (and I don't mean that in a bad way) have always like the idea of pre-authentication in a reverse proxy for Exchange server. When you implement pre-authentication at the reverse proxy, only requests from authenticated users ever get to the Exchange server. This sounds great, but I think from a practical perspective, it doesn't buy you much. It also adds significant complexity. Even with vendor support, getting pre-authentication going always seems to be a hassle. Now, if you want to implement two factor authentication for Outlook on the web/OWA, then pre-authentication is a good point to do that. Most vendors have support for adding two factor authentication. For my customers, this is seldom a concern. Recently though I ran into an issue with account lockouts caused by repeated password attacks on OWA. In this case, the user account is locked and the user can't work. There is no simple solution for this without pre-authenticatio

I was doing some analysis of an existing Exchange 2010 organization for a migration project and was wanting to calculate the average mailbox size. So, I used Get-MailboxStatistics to gather the information and export it to a csv file. Unfortunately, Get-MailboxStatistics gives you the mailbox size in this format: 2.169 GB (2,329,318,152 bytes) When you're trying to use Excel to get an average, this isn't going to work. Instead you need to get that value as an integer. To do this, you need to create your own property for the object with an integer value. The TotalItemSize property from Get-MailboxStatistics is more complex than it appears. When you use Get-Member to look at the TotalItemSize property returned by Get-MailboxStatistics, it actually contains an IsUnlimited property and a Value property. The Value property has the size of the mailbox. If you do a Get-Member on the Value property, you can see that there are methods to convert the value to an integer. For example: (Ge

I recently ran into an issue where a mailbox database content index was in a failed state after the Exchange 2010 server had a power outage. Not too big of a deal since it was in a remote site that was hosting only passive databases for disaster recovery. Normally for a passive copy, you run the following command and all is good: Update-MailboxDatabaseCopy -Identity DBName\ServerName -CatalogOnly However I got this error: A source-side operation failed. Error An error occurred while performing the seed operation. Error: An error occurred while updating the search catalog files from server 'XXXXXXX'. Error: A transient exception from Exchange Search was encountered. Error: Catalog was not paused for indexing on database dbGUID . There were only a couple of search hits for this specific error about pausing indexing and they really only indicated it was an internal process as part of the catalog reseed. There were no useful errors in the event log. I tried a few different variati