Default printer changes after Terminal Server (or print spooler service) restart

Just a quick post today.  I was troubleshooting an issue where a user would set a default network printer (say Printer01) in their user profile, upon a server restart (which happens nightly) their printer would be set back to the Adobe PDF local printer.  After going through event logs and some basic troubleshooting through Group Policy I quickly came to the conclusion that this was more of a user profile issue than a deployment one.

After a bit of Google-foo, I found that Windows stored user based printer connection details in the registry under HKEY_USERS\<user SID here>\Printers\Connections.  It also stored local settings for each printer under HKEY_USERS\<user SID here>\Printers\Settings.  I went through the printer keys under each registry key and found printers that no longer existed.

Simply deleting printers that were no longer available let the user set a default printer and the setting stayed after a server or print spooler service reboot.

How to protect all existing Organizational Units (OUs) in your Active Directory domain from Accidental Deletion by using PowerShell

We recently took on a new hire, although I was confident in their ability in managing Active Directory I wanted to take an extra step in protecting Organizational units from deletion.  I was sure that I could do this quickly using PowerShell instead of right-clicking each of our 80 odd OUs and going into their properties.

To do this we need to open the Active Directory Module for Windows PowerShell as an administrator.  Since I began in my System Admin role, I was creating OUs that were protected, so I only really needed to do this to the ones that were already here.  So first we need to work out what OUs are not protected from this list using PowerShell I can easily pipe it into the command we need to issue to protect the OUs

The first command below will output a list of all OUs currently not protected.

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | 
where {$_.ProtectedFromAccidentalDeletion -eq $false} | ft

This command does the above but also sets the ProtectedFromAccidtenalDeletion to True.

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | 
where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit 
-ProtectedFromAccidentalDeletion $true

Once this command is issued, all the Organizational Units in our Active Directory have become protected and should help prevent you from getting into those sticky situations where someone (could be you) from deleting one by mistake.

Getting Folder Sizes and number of items in a Mailbox for a particular user on Microsoft Exchange using PowerShell

Recently one of our high-end users was going over their mailbox limit. In helping them to cut down I like to let them know what folders are using up the most of their quota (generally it is their sent items folder, but sometimes not). Executing the below PowerShell command in an Exchange Administration Shell gave me a nice ordered list (see output below) of folders in their mailbox along with an associated size and number of items.

Get-MailboxFolderStatistics -Identity <username> | Sort-Object FolderSize 
-Descending | FT folderpath, foldersize, ItemsinFolder -autosize

After executing the above PowerShell you’ll get an output similar to the below

FolderPath                    FolderSize                  ItemsInFolder
----------                    ----------                  -------------
/Inbox                        32.89 MB (34,486,717 bytes)           158
/Carbon Copies                16.9 MB (17,725,567 bytes)            168
/Sent Items                   685.3 KB (701,797 bytes)               14
/Deleted Items                554.4 KB (567,723 bytes)              189
/Calendar                     27.6 KB (28,267 bytes)                  7
/Contacts                     1.492 KB (1,528 bytes)                  4
/Drafts                       138 B (138 bytes)                       1
/Sync Issues/Local Failures   0 B (0 bytes)                           0
/Sync Issues/Conflicts        0 B (0 bytes)                           0
/Sync Issues                  0 B (0 bytes)                           0
/Sync Issues/Server Failures  0 B (0 bytes)                           0

From this I can could then give to the user so they could clear out their mailbox. Hope that helps someone out.

Get-MessageTackingLog cmdlet for Exchange 2010 Returns Cannot process argument transformation on parameter ‘Start’. Cannot convert value to type “System.DateTime” because String was not recognized as a valid DateTime.

Recently, I was conducting some investigative work around mail delivery for a client.  PowerShell cmdlets for Exchange are awesome and give us as administrators some real power in trying to figure out what is wrong.  Some things in PowerShell though don’t take into account the regional language settings of the machine you’re working on.  One example of this that left me scratching my head a little was when I was running Get-MessageTackingLog. Being in Australia we do our date as dd/mm/yyyy so I had the following command ready to run

Get-MessageTrackingLog -Server SRV-MBX-02 -Start "14/08/2014 08:00:00" 
-End "14/08/2014 15:00:00" -Sender "[email protected]" | 
ConvertTo-Html > "C:\Scripts\MsgTrack.html"

When I ran this I got an error around trying to convert a DateTime, I was sure I had entered the right format (also trying – and .)

Cannot process argument transformation on parameter 'Start'. Cannot convert value "14/08/2014 08:00:00" to type "System
.DateTime". Error: "String was not recognized as a valid DateTime.
    + CategoryInfo          : InvalidData: (:) [Get-MessageTrackingLog], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-MessageTrackingLog

After a few minutes, I worked out the date needed to be in US Date/Time format of mm/dd/yyy. Swaping around my month and day got the command to work correctly and pipe out what I was after to a html page.

Interestingly, if you copy and paste a command out of the Tracking Log explorer the date and time format in there is based on the regional settings of the computer you are on, but run them through the Exchange Management Shell and you’ll also receive the above date/time error.

Backup MySQL Databases running on a Windows Server using Systems Center Data Protection Manager (DPM) 2012.

Running MySQL on a Windows machine is pretty straight forward.  One of the down sides though is that MySQL is not VSS aware and may mis-behave when back up software such as Data Protection Manager or ShadowProtect.  Data Protection Manager (DPM) has the ability (basically called Pre-Backup and Post-Backup Scripts) to perform actions before and after a backup run.

After installing the DPM Protection Agent onto the computer you want to run the protect (by default its %ProgramFiles%\Microsoft Data Protection Manager\DPM) You’ll find a Scripting Folder and inside a ScriptingConfig.xml file which should only contain XML Schema data, we will want to expand on this by adding the following lines inside ScriptConfiguration

   <DatasourceScriptConfig DataSourceName="Data source">
     ”Path\Script Parameters” 
     "Path\Script Parameters” 
     30

DataSourceName needs to be the name of the Data Source that you are protecting (matching in DPM Console) for example C:\MySQL_Backup and in our case we only want to use a PreBackupScript (ie C:\MySQL_Backup\BackupDB.cmd) which will dump a backup from our MySQL Databse into a single SQL file before the actual DPM Backup event.  As an example, the following will execute a backup for MySQL.  You will need to change -User -Password and the MaharaProd to something that suits your environment.

@echo off
set CurrentDate=%date:~-10,2%_%date:~7,2%_%date:~-4,4%
move /y C:\MySQL_Backup\Mahara-*.sql C:\MySQL_Backup\PreviousBackup.sql
mysqldump –user backupuser –password=changethis MaharaProd > C:\MySQL_Backup\Mahara-%CurrentDate%.sql

The above will output a Mahara-DD_MM_YYYY.sql file as well as make a Previous Backup before allowing DPM to go ahead and create the restore point.

Check out this TechNet article for more details on how to get this running.

Solving the FIM (Forefront Identity Manager 2010 R2) FIMService start timeout (Portal) and getting it to Start

We were recently making changes to our FIM environment where our Forefront Identity Manager boxes required restarts.  With FIM we’re always making changes in our Development kit before moving into production (which is something everyone should try do).  We quickly found that we couldn’t get back into the FIM portal and taking a quick look at the services management console we could see the FIM Service as stopped.  We had already set it to delayed start in the beginning of the setup as we found it had a much more reliable rate of starting up in our particular environment.

After some Google-fu and digging through event logs seeing entries such as simply The service did not respond to the start or control request in a timely fashion. You may also get Error 1920. Service ‘Forefront Identity Manager Service’ (FIMService) failed to start. Verify that you have sufficient privileges to start system services. Or A timeout was reached (30000 milliseconds) while waiting for the Forefront Identity Manager Service to connect. Basically, one of the main reasons for this service not starting is around .Net verifying the Authenticode signatures for the FIM service.  To try and mitigate the service timeouts we can increase how long the OS is going to wait before issuing an error by adding the following registry key onto the FIM box.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
Name: ServicesPipeTimeout
Type: REG_DWORD
Value (decimal): 60000

You could also go and disable the .Net Authenticode check by following the instructions at http://social.technet.microsoft.com/wiki/contents/articles/13946.fim-troubleshooting-fim-service-start-up-timeout.aspx.

Connection closed gracefully error when sending bulk or large quantity of e-mails in an Exchange 2007/2010 environment

I was recently helping out an old work colleague who were having issues with their CRM software and sending bulk emails through their Exchange 2010 server. After around ten minutes they would receive an error message with connection closed gracefully.  They would then have to restart their mail out and need to monitor it for this issue to ensure it didn’t get stuck every ten minutes with this error.

After poking around their receive connectors on their hub transport server I noticed that the particular connector (for their internal applications) they were using had a connection time out of 10 minutes, which would result in us receiving the connection closed gracefully error from our end user application.  The fix for this is to simply increase the ConnectionTimeout value for our Recieve Connector to anything reasonable, for us it is 3 hours. We would do by issuing the following Exchange PowerShell command:

Set-ReceiveConnector "Internal Connector - Synergetic" -ConnectionTimeout 03:00:00 -ConnectionInactivityTimeout 01:00:00

You will want to make sure that your receive connector is protected (i.e. is only set to allow internal networks) as this basically allows anything to stay connected for up to 3 hours so it could be abused.

Changing the recovery mode doesn’t shrink an SQL Database log file, how to shrink logs manually.

So I found out recently that one of our servers was running out of space.  It’s our AV server so I was like what the hell, why is it running out.  Turns out it had an instance of SQL Server on there as a quarantine and configuration database.  The Virtual Machine was being backed up but not the database itself therefore no log back ups and log truncates after that.

To check exactly how much space the logs are taking up you can run the following SQL cmd:

SELECT * FROM <database>.sys.sysfiles

Or you could just as easily right-click the database and check file sizes from there.

To fix this I simply changed the recovery mode from FULL to Simple for the databases, but without a backup of the databases themselves the logs wouldn’t truncate.  Doing a backup from the right-click menu won’t truncate them either.  Since I wasn’t really worried about backing up the database itself I could just force SQL Server to truncate the logs.  I ran the following command to shrink the log file:

DBCC SHRINKFILE('<database_log>')

With <database_log> being the name of the database log file you want to shrink.  That solves that problem.

Fixing KDC Authentication Problems when upgrading your domain and forest functional level from 2003 to 2008 R2

We recently upgraded our Domain and Forest Functional Level from 2003 to 2008 R2, after a day or so I started having problems connecting to a number of 2008 R2 Hyper-V Virtual Machines. When attempting to connect I would receive the following error:
An Authentication Error Has Occurred. The Encryption Type Requested Is not supported by the KDC
At around the same time we also had one of our Exchange 2010 Transport Servers stop servicing clients, when I attempted to open the Exchange management console on the local server console ended with a HTTP server error status 500 and “Kerberos” authentication failed. So I decided to take a look through the event viewer to see what was up.

As part of Exchange there is an Active Directory Topology Service which will scan your environment for Active Directory Servers every 15 minutes or so, all of the exchange services rely on this service (if you ever have to restart all exchange services, simply restart the AD Topology Service). In the application event log I noticed the following error message:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=xxxx). Topology discovery failed, error 0×80040952 (LDAP_LOCAL_ERROR (Client-side internal error or bad LDAP message))….
There were also issues with the Exchange STORE service with the following two events:
Process STORE.EXE (PID=xxxx). All Global Catalog Servers in forest DC=xxx,DC=xx,DC=xx are not responding.
Process STORE.EXE (PID=xxxx). All Domain Controller Servers in use are not responding

The rather simple resolution to all this trouble is simply to restart the KERBEROS DISTRIBUTION KEY or KDC service on all Domain controllers. While simply restarting the Service will solve the problem, you’re probably better off just doing a proper restart after upgrading your functional levels, only from 2003 to 2008 / 2008 R2.

Update WSUS 3.0 SP2 to support Windows 8 and Windows Server 2012 Clients

Just a quick one today.  Microsoft have released an update for those running WSUS 3.0 SP2 which allows you  to provide updates to clients running Windows 8 and Server 2012.  The update is available at this Knowledge Base Article for both 32 and 64 bit environments.

Also, no word yet on when they will be releasing a patch for the IE flaw (see here and here), but should be available over the next few days.