I needed to recover an Exchange 2007 mailbox using DPM 2012 recently and thought I would share with you the steps I took.
Although there have been many – very good – advances made in System Center Data Protection Manager 2012, the Exchange Item Level Recovery is still in need of some work. Continue Reading
We have a rather complex setup for sharing out user documents on our domain, this has thrown up a problem whereby the users Home Folder shows as “Documents” instead of folder name.
We have a heady mix of;
In Active Directory Users and Computers (ADUC) we have the profile path pointing to a mandatory profile on;
\\SERVER\SHARE\PROFILES\USERGROUP
(we have multiple mandatory profiles for different user groups)
Also we have the Home Folder set to connect an F: drive to;
\\SERVER\SHARE\SURNAME_INITIAL\USERNAME
(we split our users by Surname Initial to make it easier to manage)
ADUC User Properties
Then through Group Policy we redirect the Documents folder to the Users Home Directory as defined in ADUC.
Group Policy Manager
All was fine until we migrated all our users over to Windows 7.
This was when the problem of users Home Folder shows as “Documents” instead of folder name came about.
In Everyday use this is not a massive issue but it was slightly annoying. Especially if you need to find a users file quickly.
User Share
I searched around and found a few pointers;
None of these fit with my situation, there was however a mention here on Edugeek of using File Server Resource Manager.
Here are the steps I followed;
In “File Server Resource Manager”
In “File Screening Management”
Under “File Screens”
Create a new File Screen for the physical drive on the file server where the user shares reside – in our case K:\
I created a new “File Group” in this case to block only desktop.ini files.
File Server Resource Manager
This then meant that no users can create new desktop.ini files.
However the old files were still there so to delete these files I turned to Powershell.
I prefer to use Windows Powershell ISE.
I used the get-childitem cmdlet to firstly list all the desktop.ini files.
get-childitem \\SERVER\SHARE\SURNAME_INITIAL\USERNAME -filter desktop.ini -force
The -filter option will display only the desktop.ini files
The -force option will display hidden files (I did wonder why I got no results initially!)
This should list all occurences of desktop.ini files.
I then piped the results into the remove-item cmdlet
get-childitem \\SERVER\SHARE\SURNAME_INITIAL\USERNAME -filter desktop.ini -force | foreach ($_) {remove-item $_.fullname -force -whatif}
Here the -force option will delete hidden and system files.
The -whatif option is very handy and just runs a “test” of the script and gives you an idea of what will happen.
Finally remove the -whatif and delete all desktop.ini files.
get-childitem \\SERVER\SHARE\SURNAME_INITIAL\USERNAME -filter desktop.ini -force | foreach ($_) {remove-item $_.fullname -force}
I then tested the setup by logging on as a user and the problem was resolved.
All is good in the hood!
Best Practice Analyzer on one of our Domain Controllers was reporting; “All OUs in this domain should be protected from accidental deletion.”
Using Active Directory Administrative Center right click and OU and select properties, on the Object Tab is a checkbox “Protect from accidental deletion”
Protect From Accidental Deletion
You could also use Active Directory Users and Computers you can right click and OU and select properties, on the Object Tab is a checkbox “Protect object from accidental deletion”
However if like me your AD is complex with lots of OU’s you may want to do this a little bit quicker.
Enter Powershell!
Using “Active Directory Module for Windows PowerShell”
First check which OUs aren’t protected:
Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | ft
Then to protect them:
Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true
Then rerun the first command to verify the change has been made, you should get no results.
You could then double check using Active Directory Administrative Center or ADUC.