Backup schlägt seit den November-Updates mit VSS-Fehlern fehl

Jeden zweiten Dienstag im Monat ist bekanntlich der Patchday an dem wichtige Updates bereitgestellt werden. Im November war darunter das Update 3000853, welches ein Update-Rollup unter anderem  für Windows Server 2008 R2 und Windows Server 2012 mit mehren kleineren Hotfixen ist. Durch das Update sollen folgende Probleme behoben werden:

  • 3004905

    Windows Hyper-V improvement for Linux virtual machines that have file systems that are larger than 2 TB

  • 3004542

    Windows Server 2012-based cluster responds to requests slowly

  • 3004540

    Memory usage becomes high when you run an application in Windows 8 or Windows Server 2012

  • 2995478

    Wmiprvse.exe memory leak when a program queries disk or partition storage information in Windows Server 2012

  • 2970215

    Microcode update for Intel processors to improve the reliability of Windows Server

  • 2891362

    A file copy operation fails when files or folders have long paths in Windows Explorer

  • 3002653

    Update to support AAC and LATM format audios in Windows 8.1 or Windows 8

  • 2996928

    Backup task fails with a time-out error in Windows Server 2012 or Windows Server 2008 R2

  • 3001266

    Office documents freeze when saving through a slow network on a domain-joined computer in Windows 8.1 or Windows 8

Nach der Installation des Updates kann es dazu kommen, dass die tägliche Datensicherung allerdings mit VSS-Fehlern (Zeitüberschreitung) fehlschlägt. In den Foren hat man dazu hauptsächlich im Bereich SQL-Server gelesen, es waren aber auch Sicherungen des Betriebssystems bzw. Sicherungen auf Fileebene davon betroffen. Schuld daran ist das Update 2996928 bei der versehenlich eine falsche Version dem Update-Rollup beigefügt wurde. Damit das Backup wieder lief blieb einem nur die Möglichkeit das Update 3000853 komplett zu deinstallieren. Microsoft hat ziemlich schnell reagiert und hat ein aktualisiertes Update 2996928 herausgebracht, welches man als Übergangslösung auf den betroffenen System installieren konnte.

Seit heute wurde eine neue Version des Updates 3000358 über Windows-Update herausgegeben, welches auf den Systemen zur Installation angeboten wird, dieses beinhaltet die richtige Version des Updates 2996928. Wer das Update 2996928 manuell auf den Systemen installiert hat braucht das neue Update 3000358 nicht erneut zu installieren. Ebenso lässt sich das Update 2996928 nicht auf Systemen installieren auf denen bereits das aktualisierte Update 3000358 installiert wurde.

 

0  

Ändern des Anmeldenamens in Exchange Online Protection

Die Migrationen von FOPE zu EOP sind derzeit ja voll im Gange und es sind nach der Migration einige Schritte notwendig um die Migration abzuschließen. Eine Aufgabe davon ist es die Verzeichnissynchronisierung wieder zu konfigurieren, so dass die gültigen E-Mail-Adressen abgeglichen werden und dadurch ein Edge-Blocking (Abweisen von nicht gültigen E-Mail-Adressen) vorgenommen werden kann.  EOP verwendet dazu Microsoft Azure Active Directory und die Benutzer bzw. deren E-Mail-Adressen werden über das dazugehörige Dirsync-Tool synchronisiert.

Eigentlich ist die Einrichtung der Verzeichnissynchronisierung keine große Sache und in den meisten Fällen gleicht es auch der Installationsart Weiter-Weiter-Fertig. Wer vorher allerdings nicht den Standarddomainnamen von der onmicrosoft.com-Domain zu seiner eigenen Domain ändert bekommt automatisch alle Benutzer mit dem onmicrosoft.com-Domainsuffix angelegt, was nicht unbedingt gewollt ist, wenn sich die Benutzer evtl. später einmal damit Online anmelden sollen.

Abhängig von der Unternehmensgröße kann die manuelle Änderung des Anmeldenamens ziemlich lange dauern. Hinzu kommt allerdings noch, dass bei Benutzern die über das Dirsync-Toll synchronisiert werden manche Werte nicht über die GUI geändert werden können, unter anderem auch das Domainsuffix für die Anmeldung.

Wenn man also vergessen hat die Standarddomain festzulegen sieht der Ergebnis nach der ersten Synchronisation wie in folgendem Bild gezeigt aus.

eop_username1

Mit Hilfe von Powershell kann dies allerdings ganz einfach wieder korrigiert werden. Dazu muss auf einem Client das Powershell-Modul für Microsoft Azure Active Directory installiert sein. Wie das geht und was dazu benötigt wird ist in folgendem Artikel genau beschrieben. Nach erfolgreicher Installation startet man die Powershell für Microsoft Azure Active Directory über die erstellte Verknüpfung und verbindet sich mit dem Powershell-Befehl connect-msolservice mit seinem Account von Microsoft Azure Active Directory. Der erste Schritt ist somit schon erledigt, jetzt muss nur noch folgendes Powershellskript ausgeführt werden und alle Benutzer werden automatisch auf das richtige Domainsuffix geändert. Vorher müssen allerdings noch im Powershellskript die Werte für die onmicrosoft-Domain und die richtige Domain in den Variablen $ondomain und $mydomain angepasst werden.

Speichern Sie dazu zunächst folgendes Powershellskript auf dem Rechner unter dem Namen Rename_User.ps1 ab.


$ondomain =”groebynet.onmicrosoft.com”
$mydomain =”groeby.net”

$users = get-msoluser | where {$_.Userprincipalname -like (“*”+$ondomain)}foreach ($user in $users)
{

$dummy = $user.Userprincipalname.Replace($ondomain,$mydomain)
Set-MsolUserPrincipalName -ObjectId $User.objectid -NewUserPrincipalName $dummy

}


Nachdem die Variablen auf Ihre Werte angepasst wurden muss das Powershellskript ausgeführt werden und die Anmeldenamen der Benutzer werden automatisch auf die richtige Standarddomain gesetzt. In der Verwaltungswebsite unter dem Punkt Benutzer und Gruppen ist das Ergebnis nun zu sehen.

eop_username2

Alle Benutzer haben nun als Anmeldenamen das richtige Domainsuffix. Damit Benutzer die später synchronisiert werden automatisch das richtige Domainsuffix erhalten muss dieses in der Verwaltungswebsite geändert werden. Dazu klickt man rechts oben direkt unter dem Benutzernamen auf den Link mit dem Firmennamen.

eop_username3

Dort dann das richtige Standarddomainsuffix unter dem Punkt Default Domain auswählen und abspeichern.
eop_username4

0  

Hotfix für Forefront Protection 2010 für Exchange verfügbar

Für Forefront Protection 2010 für Exchange ist seit kurzem ein Hotfix verfügbar der eine Sicherheitslücke schließt über die schadhafter Code ausgeführt werden kann.

Der Hotfix kann unter Url http://www.microsoft.com/en-us/download/confirmation.aspx?id=41836 heruntergeladen werden. Die dazugehörige Beschreibung findet man hier: http://support.microsoft.com/kb/2927022/en-us

Voraussetzung für die Installation des Hotfixes ist das installierte Rollup 4 für Forefront Protection 2010 für Exchange. Falls dies noch nicht installiert ist kann es hier heruntergeladen werden. Die installierte Version von Forefront Protection 2010 für Exchange findet man in der Verwaltungskonsole über den Menüpunkt Hilfe -> Info heraus. Die Versionsnummer für Rollup 4 ist 11.0.727.0. Sollte sich die installierte Version von dieser Versionsnummer unterscheiden bitte erst das Rollup 4 installieren. Für den Fall, dass eine etwas ältere Version von Forefront Protection 2010 für Exchange installiert ist kann das Rollup 4 direkt installiert werden, es müssen keine vorigen Rollups zuvor installiert sein.

Eine Übersicht über die aktuellen Rollups für Forefront Produkte gibt es übrigens hier.

0  

Backup der Switchkonfiguration per Powershell

Jedes Netzwerk benötigt Switche, um die Kommunikation zwischen PCs mit den Servern und anderen Periperiegeräten zu ermöglichen. In kleineren Unternhemen sind meistens einfache Switche ohne Konfigurationsmöglichkeit ausreichend. Je größer jedoch das Unternehmen wird wächst meistens auch die Anforderung an die Switche. Deshalb müssen diese konfigurierbar sein, um z.B. mehrere VLANs zu verwalten oder gewisse Einstellungen an den Ports vorzunehmen. Mit den gewachsenen Anforderungen wird auch die Konfiguration komplizierter und umfangreicher. Ein Switch wird sehr oft vernachlässigt, da dies ein Gerät ist, welches sich in einem Netzwerkschrank befindet und fröhlich vor sich hin blinkt. Solange der Switch funktioniert ist alles gut, aber sollte der Switch nach einem Defekt nicht mehr funktionsfähig sein, so hat man ein Problem. Einen neuen Switch zu organisieren ist dabei das geringste Problem. Ein viel größeres Problem ist es die Konfiguration wieder herzustellen, sofern man keine Dokumentation besitzt. Letzteres ist wohl auch eher selten der Fall :-).

Mit Hilfe des folgenden Powershell-Skripts kann man automatisiert die Konfiguration von Switchen per Telnet auslesen und diese als Datei auf einem Server ablegen. Sollte somit zu einem späteren Zeitpunkt der Switch kaputt gehen, so hat man wenigstens die Konfiguration gesichert und kann diese im günstigsten Fall einfach in den neuen Switch importieren. Als Voraussetzung hierfür werden folgende Komponenten beöntigt:

Ein TFTP-Server ala TFTP32
Ein Server oder Client mit installierter Powershell
Aktivierter Telnet-Zugriff auf die Switche

 

Als Grundlage des Skripts kommt hier das Telnet-Skript von Martin Pugh zum Einsatz. Mit Hilfe dieser Funktion kann eine Verbindung über Powershell zu Geräten hergestellt und können Befehle an diese abgesetzt werden. Zunächst aber muss der TFPT-Server auf dem Client installiert werden. Sofern dies erledigt ist kopieren Sie das Skript per Copy&Paste in einen Editor Ihrer Wahl und speichern Sie dieses als backup_switch.ps1 auf dem Client ab. Für das Skript werden zwei Unterordner benötigt, in denen zum einen die Befehlsskripte und die Logfiles abgelegt werden. Wenn Sie z.B. das Skript nach C:\Skripte\Switchbackup kopiert haben, so erstellen Sie bitte die beiden Ordner Commands und Logs darunter. Sollten Sie einen anderen Pfad gewählt haben, so müssen Sie noch die Variable $BaseDir auf diesen Pfad anpassen. Je nachdem, welchen TFTD-Server Sie ausgewählt haben muss auch noch die Variable $TftpServiceName auf den entsprechenden Dienstnamen angepasst werden.


# Function to connect to remotehosts over telnet
 Function Get-Telnet
 {
   Param (
   [Parameter(ValueFromPipeline=$true)]
   [String[]]$Commands = @(“username”,”password”),
   [string]$RemoteHost = “IPAddress”,
   [string]$Port = “23”,
   [int]$WaitTime = 1000,
   [boolean]$Debugging = $false
   )

   $Socket = New-Object System.Net.Sockets.TcpClient($RemoteHost, $Port)
   If ($Socket)
   {
     $Stream = $Socket.GetStream()
    $Writer = New-Object System.IO.StreamWriter($Stream)
    $Buffer = New-Object System.Byte[] 1024
    $Encoding = New-Object System.Text.AsciiEncoding

    ForEach ($Command in $Commands)
    {
     $Writer.WriteLine($Command)
     $Writer.Flush()
     Start-Sleep -Milliseconds $WaitTime
    }
    Start-Sleep -Milliseconds ($WaitTime * 4)
    $Result = “”

    While($Stream.DataAvailable)
    {
     $Read = $Stream.Read($Buffer, 0, 1024)
     $Result += ($Encoding.GetString($Buffer, 0, $Read))
    }
   }
   Else
   {
    $Result = “Unable to connect to host: $($RemoteHost):$Port”
   }

   if ($Debugging)
   {
    $Result | Out-File ($BaseDir +”\Logs\”+ $RemoteHost +”_log.txt”)
   }
  }

Global settings
 $BaseDir =”C:\Skripte\Switchbackup\”
 $TftpServiceName =”Tftpd32_svc”

# Start program here
 Start-Service $TftpServiceName

 $files = Get-ChildItem -Path ($BaseDir + “\Commands\”)

 foreach ($file in $files)
 {
  $remotehost = $file.BaseName
  $commands = Get-Content ($BaseDir + “\Commands\” + $file.Name)

  Get-Telnet -Commands $commands -RemoteHost $remotehost -Debugging:$false
 }

 Stop-Service $TftpServiceName


 
Jetzt fehlen für das Backup der Switche noch die Konfigurationsdateien. Diese müssen im Verzeichniss Commands abgelegt werden. Dazu gibt es zu beachten, dass der Dateiname gleich dem Hostnamen bzw. der IP-Adresse sein muss. Soll die Konfiguration des Switches mit der IP-Adresse 192.168.1.1 gesichert werden, so muss die Datei auch 192.168.1.1.txt heissen. Anhand des Dateinamens wird später die Verbindung zum Switch hergestellt. In der Datei selbst stehen die Befehle, wie sie auch in der Console eingegeben werden müssen, um das Backup zu erstellen. Folgend ein Beispiel für ein Backup-Skript.
 
Dateiname: 192.168.1.1.txt


user
password
enable
copy running-config startup-config
y
copy running-config tftp://192.168.1.100/Switches/192.168.1.1.cfg
y
exit
exit


 
Das Powershell-Skript startet zu Beginn den TFTP-Server und liest danach alle Dateien des Commands-Verzeichnisses ein und durchläuft diese in einer Schleife. Dabei werden die Befehle aus der Datei gelesen und anschließend eine Telnet-Verbindung zum Switch hergestellt. Innerhalb der Verbindung werden die Befehle aus der Textdatei nacheinander gesendet und diese somit ausgeführt. Wurden alle Befehlsdateien durchlaufen wird im Anschluß daran der TFTP-Server wieder beendet. Falls gewünscht kann durch ändern des Parameters Debugging auf den Wert $true die Protokollierung einschalten. Dabei werden die Logfiles im Ordner Logs abgelegt.
 

Beachten Sie, dass hier Benutzername und Kennwort in der Textdatei im Klartext abgespeichert werden und somit einfach lesbar sind. Sie sollten mittels Dateisystemberechtigungen dafür sorgen, dass keine unbefugte Person Zugriff auf diese Dateien bekommt. Zudem handelt es sich bei einer Telnet-Verbindung um eine unverschlüsselte Verbindung, d.h. auch hier werden Benutzername und Kennwort im Klartext übertragen. Eine bessere Alternative wäre hier SSH, sofern dies von den Switchen unterstützt wird. Hierfür kann dieses Powershell-Skript allerdings sehr gut als Ansatz genommen werden.

HINWEIS: Wer möchte kann dieses Skript gerne einsetzen und für seine Bedürfnisse anpassen. Ich übernehme allerdings keine Haftung für eventuelle Probleme oder Schäden, die mit dem Einsatz des Skriptes auftreten! Die Verwendung des Skripts erfolgt somit auf Ihre eigene Gefahr!

0  

Änderungen an der Forefront Roadmap – Forefront UAG eingestellt

Heute wurden über den Server & Cloud Blog weitere Änderungen in der Forefront Roadmap angekündigt.

– Forefront UAG wird eingestellt
– Im ersten Halbjahr 2015 wird es eine neue Version von Forefront Identity Manager geben

Grund für das Einstellen von UAG sind die bereits in Server 2012 enthaltenen Funktionen, die in Zukunft für die Veröffentlichung von Direct Access und internen Servern verwendet werden sollen. Aus diesem Grund erhalten Kunden die Lizenzen von UAG über einen Vertrag mit Software Assurance besitzen eine Windows Server-Lizenz dafür. Natürlich lässt sich eine Installation von UAG nicht von heute auf morgen umstellen, deshalb gibt es Mainstream-Support bis 14.04.2015 und Extended Support bis 14.04.2020.

Den Originalartikel findet Ihr hier:

http://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx

0  

Abfragen von Druckerinformationen per Powershell

In Unternehmen werden Drucker häufig zusammen mit einem Wartungsvertrag geleast, der die Drucker, den Toner und die Ersatzteile sowie die Wartung enthält. Im Leasingvertrag ist dann auch meistens eine bestimmte Anzahl an gedruckten Seiten vereinbart die im Preis inklusive sind. Abhängig davon wie es im Vertrag vereinbart ist müssen die gedruckten Seiten in bestimmten Intervallen übermittelt werden, damit die Mehrausdrucke abgerechnet werden können. Dazu verwenden die Hersteller gerne eine Blackbox die sie in das Unternehmensnetzwerk einbinden. Diese Box fragt automatisch die Zählerstände und das Verbrauchsmaterial ab und übermittelt diese an den Hersteller. Somit kann z.B. auch automatisch Toner nachbestellt werden, wenn dieser bei einem Drucker zu Ende geht. Zum Einsatz kommt hier das SNMP-Protokoll, mit dem die Information aus den Druckern ausgelesen werden.

Sehr vielen Administratoren ist diese Blackbox äußerst suspekt, da diese nicht wirklich wissen, was diese Box sonst noch alles in ihrem Netzwerk veranstaltet. Als Alternative bleibt dem Administrator dann nur übrig die Zählerstände manuell auszulesen, was ziemlich mühsam werden kann. Es gibt aber auch eine einfache Methode die Zähler- und Tonerstände zu ermitteln, wenn man nicht bereit ist sich eine Blackbox ins Unternehmensnetzwerk zu stellen. Wie bereits erwähnt verwenden diese Blackboxen das SNMP-Protokoll um an die Information zu gelangen. Es gibt zahlreiche Freeware-Tools mit denen man SNMP-Abfragen an Geräte schicken kann. Eines ist z.B. das Tool SNMP-Tools von digigrupp.com. Dieses Tool arbeitet in der Eingabeaufforderung ohne GUI, was es ermöglicht die Abfragen per Skript zu automatisieren. Was man für die Abfrage der Zähler- und Tonerstände benötigt ist die sogenannte OID, eine numerische Adresse an der die Information hinterlegt ist. Diese OID ist leider von Hersteller zu Hersteller unterschiedlich, aber die OIDs sind mit Hilfe der Suchmaschine seiner Wahl problemlos herauszufinden.

Folgendes Skript bietet einen Ansatz, wie man mit Hilfe von Powershell und einem SNMP-Tool die Zähler und Tonerstände von Druckern automatisiert auslesen und sich diese per E-Mail zusenden lassen kann.


#Global settings

$stats =””

$CAN_Printers =(“192.168.150.235″,”192.168.150.236″,”192.168.150.237″)
$CAN_SNOID =”1.3.6.1.4.1.1602.1.2.1.4.0″
$CAN_IDOID =”1.3.6.1.2.1.1.5.0″
$CAN_PC1OID =”1.3.6.1.4.1.1602.1.11.1.3.1.4.112″
$CAN_PC2OID =”1.3.6.1.4.1.1602.1.11.1.3.1.4.106″
$CAN_PC3OID =”1.3.6.1.4.1.1602.1.11.1.3.1.4.109″
$CAN_TLBOID =”1.3.6.1.2.1.43.11.1.1.9.1.1″
$CAN_TLCOID =”1.3.6.1.2.1.43.11.1.1.9.1.2″
$CAN_TLMOID =”1.3.6.1.2.1.43.11.1.1.9.1.3″
$CAN_TLYOID =”1.3.6.1.2.1.43.11.1.1.9.1.4”

# Collect information from Canon Color printers
foreach ($printer in $CAN_Printers)
{
#Drucker aufwecken
$ping = “C:\Windows\system32\ping.exe ” + $printer + ” -n 10″
$foo = Invoke-Expression $ping

#Verbindung zu Drucker prüfen
$ping = “C:\Windows\system32\ping.exe ” + $printer + ” -n 1″
$foo = Invoke-Expression $ping

if ($foo -like (“*Empfangen = 1*”))
{

$dummy = “`r`n”

$sn_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_SNOID
$id_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_IDOID
$pc1_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_PC1OID
$pc2_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_PC2OID
$pc3_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_PC3OID
$tlb_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_TLBOID
$tlc_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_TLCOID
$tlm_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_TLMOID
$tly_cmd = “C:\Skripte\PrinterAccounting\snmptools.exe /v /query /h:” + $printer + ” /o:”+$CAN_TLYOID

$sn = Invoke-Expression $sn_cmd
$id = (Invoke-Expression $id_cmd).Replace(“?”,””)
$pc1 = Invoke-Expression $pc1_cmd
$pc2 = Invoke-Expression $pc2_cmd
$pc3 = Invoke-Expression $pc3_cmd
$tlb = Invoke-Expression $tlb_cmd
$tlc = Invoke-Expression $tlc_cmd
$tlm = Invoke-Expression $tlm_cmd
$tly = Invoke-Expression $tly_cmd

$dummy += “Druckername: ” + $id + “`r`n”
$dummy += “Seriennummer: ” + $sn + “`r`n”
$dummy += “Seitenzähler A3 schwarz: ” + $pc1 + “`r`n”
$dummy += “Seitenzähler A4 farbe: ” + $pc2 + “`r`n”
$dummy += “Seitenzähler A4 schwarz: ” + $pc3 + “`r`n”
$dummy += “Tonerlevel black: ” + $tlb + “`r`n”
$dummy += “Tonerlevel cyan: ” + $tlc + “`r`n”
$dummy += “Tonerlevel magenta: ” + $tlm + “`r`n”
$dummy += “Tonerlevel yellow: ” + $tly + “`r`n”

$stats += $dummy

}

}

Send-MailMessage -SmtpServer 192.168.150.3 -From “drucker@domain.invalid” -Subject “Druckerauswertung” -To “druckeradmin@domain.invalid” -Body: $stats -Encoding “UTF8”


Am Anfang des Skripts werden die IP-Adressen der Drucker in einem Array abgespeichert, über das später geloopt wird. Die OIDs mit den gewünschten Informationen werden in einzelnen Variablen abgelegt. Danach beginnt das Skript über die einzelnen IP-Adressen zu durchlaufen. Da es vorkommen kann, dass sich die Drucker im Standby-Modus befinden wird zunächst der Drucker mit 10 Ping-Anfragen aufgeweckt. Im Anschluss daran wird eine weitere Ping-Anfrage an den Drucker gesendet, um sicher zu stellen, dass der Drucker erreichbar und nicht ausgeschalten ist, dazu wird überprüft ob die eine Ping-Anfrage erfolgreich war.
Wenn der Drucker erreichbar ist, dann wird in weiteren Variablen pro OID die Syntax für den Aufruf des SNMP-Tools zusammengesetzt und diese im Anschluss ausgeführt. Das Ergebnis der Abfragen wird wiederum in Variablen gespeichert, damit diese später weiterverarbeitet werden können, wie z.B. eine Prüfung ob der Tonerstand niedriger als 10% ist. In diesem Beispielskript werden die Ergebnisse nur dazu genutzt, um die Werte per E-Mail an den zuständigen Administrator zu schicken.

Per geplantem Task kann man nun wöchentlich oder monatlich sich die Werte automatisiert aus den Druckern auslesen lassen und muss somit nicht die Zählerstände per Hand ablesen. Mit Hilfe dieses kleinen Skripts ist es somit möglich auf die Blackbox der Hersteller zu verzichten und kann trotzdem komfortabel die Informationen aus den Druckern an den Hersteller übermitteln.

HINWEIS: Wer möchte kann dieses Skript gerne einsetzen und für seine Bedürfnisse anpassen. Ich übernehme allerdings keine Haftung für eventuelle Probleme oder Schäden, die mit dem Einsatz des Skriptes auftreten! Die Verwendung des Skripts erfolgt somit auf Ihre eigene Gefahr!

0  

Rollup 4 für Forefront TMG 2010 SP2 verfügbar

Seit letzter Woche ist das Rollup 4 für Forefront TMG 2010 SP2 verfügbar. Dieses Rollup enthält folgende kleine Fehlerkorrekturen:

2889345 FIX: Accounts are locked out beyond the AccountLockoutResetTime period in Forefront Threat Management Gateway 2010 SP2
2890549 FIX: Incorrect Performance Monitor values when queried from a .NET Framework app in Forefront Threat Management Gateway 2010
2890563 FIX: “URL” and “Destination Host Name” values are unreadable in the web proxy log of Forefront Threat Management Gateway 2010
2891026 FIX: Firewall Service leaks memory if Malware Inspection is enabled in Forefront Threat Management Gateway 2010
2888619 FIX: A password change is unsuccessful if a user’s DN attribute contains a forward slash and an Active Directory LDAP-defined special character in Forefront Threat Management Gateway 2010
2863383 FIX: “Query stopped because an error occurred while it was running” when you run a non-live query in Forefront Threat Management Gateway 2010 SP2
2899720 FIX: Threat Management Gateway 2010 incorrectly sends “Keep-Alive” headers when it replies to Media Player WPAD file requests
2899716 FIX: Firewall service (Wspsrv.exe) crashes when a web publishing request is handled in Forefront Threat Management Gateway 2010
2899713 FIX: Access to certain SSL websites may be unavailable when HTTPS Inspection is enabled in Forefront Threat Management Gateway 2010
0  

Löschen eines Mobilgeräts in der Exchange EMC schlägt fehl

Heutzutage ist es keine Seltenheit mehr, dass Mitarbeiter ihre E-Mails auf mobilen Endgeräten, wie einem Smartphone oder einem Tablet, empfangen. Mit der Zeit werden auch diese Geräte nach und nach durch modernere Geräte ersetzt, welche dann logischer Weise wiederum die E-Mails empfangen können. In Exchange Server steht dazu das ActiveSync-Protokoll zur verfügung, über die die mobilen Endgeräte angebunden werden können.

Die vom Benutzer angemeldeten Enggeräte kann man in der Exchange Verwaltungskonsole im Kontextmenü des Benutzers über den Eintrag Mobiltelefon verwalten verwalten. Dazu gehören die Aufgaben des Remotewipe oder der einfachen Entfernung der Partnerschaft. Letzteres ist z.B. sinnvoll, wenn der Mitarbeiter ein neues Smartphone erhalten hat und das Alte somit nicht mehr in Gebrauch ist.

Mange mobile devices

Obiges Bild zeigt ein Beispiel für ein Windows Phone 7-Gerät, welches seit dem 11.04.2013 nicht mehr synchronisiert wurde. Genau dieses Gerät soll jetzt über die Exchange EMC aus den Partnerschaften über die Option Mobiltelefonpartnerschaft entfernen gelöscht werden. Dazu wählt man oben das entsprechende Gerät aus und klickt dazu auf die Schaltfläche Entfernen. Eigentlich keine große Angelegenheit.

Delete Device failed

Leider schlägt die Entfernung der Partnerschaft mit obiger Fehlermeldung fehl. Das Gerät wurde nicht gefunden?

WPDELETE4

Schaut man in der Verwaltungskonsole für Benutzer und Computer des Active Directorys (ADUC) unterhalb des Benutzers nach, so findet man ein Gerät genau mit dieser GUID. Wer jedoch genau hinsieht findet das Problem. In der fehlgeschlagenen Löschung des Geräts über die EMC enthält die Identity 1.Stock und im ADUC sieht man, dass der Benutzer im 2. Stock arbeitet, somit ändert sich natürlich die Identity für das Gerät. Konkret hat hier der Mitarbeiter die Position gewechselt und ist dadurch vom 1. Stock in den 2. Stock umgezogen, was im ADUC durch verschieben des Benutzers realisiert wurde, damit auf diesen auch die richtigen Gruppenrichtlinen angewendet werden. Wie bekommt man das alte Smartphone nun doch entfernt?

Betrachtet man die ganze Sache über die Powershell (Exchange Management Shell), dann erhält man über das Commandlet get-ActiveSyncDevice mit Filterung auf einen Teil des Namens des Benutzers  folgendes Ergebnis:

WPDELETE3

Wie man gut erkennen kann erhält man über die Powershell die richtige Identity mit 2.Stock als Bestandteil, so wie laut ADUC auch der korrekte Pfad dahin ist. Über den aktivierten Quick Edit-Modus kann man sich nun die Identity in die Zwischenablage kopieren und anschließend mit dem Befehl Remove-ActiveSyncDevice -Identity <Paste Identity hier> das Gerät erfolgreich entfernen. Warum dies so ist kann ich leider nicht erklären, aber dank Powershell kann man das Gerät trotzdem entfernen.

 

0  

Virtuelle Maschine lässt sich nicht starten, wenn ein Bandlaufwerk am Server angeschlossen ist

Auf einem Windows Server 2012 mit installierter Hyper-V-Rolle lies sich urplötzlich keine der bereits vorhandenen virtuellen Maschinen mehr starten. Der Server war so eigentlich schon ein paar Tage in Betrieb, als letzte Änderung wurde eigentlich nur  eine Tape-Library per Fibre-Channel an den Server angeschlossen. Grund für die virtuellen Maschinen auf dem Server mit der Tape-Library ist, dass auf dem Backup-Server ein DC betrieben wird damit der Cluster gestartet werden kann.

Im Ereignisprotokoll findet man dazu folgende Fehlermeldung:

Hyper-V-VMMS 27000

Recherchiert man etwas dazu über die Suchmaschine seiner Wahl, so findet man schnell folgenden KB-Artikel http://support.microsoft.com/kb/2013544.
In diesem steht dann folgender Satz: “Turn off any attached tape device and restart the server. As soon as the server is started, turn on the tape device.”

Ich hätte nie gedacht, dass es wirklich am neu angeschlossenen Bandlaufwerk liegen kann. Problem scheint zu sein, dass hier die Treiber für das Bandlaufwerk einen Konflikt mit den Treiber für das VHD-Dateisystem verursachen. Die Lösung ist ganz einfach, man muss in der Registrierung nur die Startart des Dienstes von Manuell (3) auf Boot (0) stellen, damit dieser vorher geladen wird. Nach einem Reboot hatte ich allerdings das gleiche Problem immer noch. Was nun? Weitere Informationen oder Lösungsansätze habe ich dazu im Internet nicht wirklich gefunden, also hieß es ausprobieren.

Folgendes brachte mir die Lösung:

Mit dem Hintergrundwissen, dass hier der Treiber für das Bandlaufwerk anscheinend vor dem Treiber für VHDs geladen wird und es somit zu Problemen kommt liegt die Lösung eigentlich ziemlich nahe. Ich muss versuchen, dass der Treiber für VHDs eben vor dem Bandlaufwerk geladen wird. Einfacher gesagt als getan, denn man muss erstmal herausfinden welcher Dienst hierfür zuständig ist :-).
Ok, so schwer war es dann auch nicht, der Dienst heisst VHDMP (HKLM\System\CurrentControlset\Services\VHDMP) und kann ebenfalls über die Registrierung bearbeitet werden. Die Treiber für das Bandlaufwerk werden ganz normal zu einem späteren Zeitpunkt des Systemstarts gestartet, aber anscheinend immer noch vor den Treibern für den Zugriff auf VHDs. Schaut man sich die Einstellungen des Diensts VHDMP an, so steht die Startart ebenfalls auf dem Wert 3 (Manuell). Ziel ist es nun den Dienst VHDMP vorher zu starten, also habe ich die Startart auf den Wert 0 (Boot) gestellt, somit sollte dieser auf jeden Fall vorher gestartet werden. Das folgende Bild zeigt die Einstellungen, die geändert werden müssen.

vhdmp start

Nach einem Neustart des Systems wurden alle virtuellen Maschinen automatisch gestartet und funktionierten somit einwandfrei. Auch die Backup Software machte keine Probleme.

 

 

 

0  

Exchange 2010 SP3 Rollup 1 verursacht Probleme

Vor einigen Tagen hat Microsoft das Rollup 1 für Exchange Server Servicepack 3 veröffentlicht. Nachdem das Rollup installiert wurde erhielt ich sofort eine Meldung von Forefront Protection 2010 für Exchange Server, dass der Transport Dienst unerwartet beendet wurde. Der Inhalt der E-Mail-Benachrichtigung sieht wie folgt aus:


Betreff: Microsoft Forefront Protection for Exchange Server: Kritische Benachrichtigung

FEHLER: Microsoft Forefront Protection for Exchange Server: Der Monitor hat das nicht ordnungsgemäße Herunterfahren erkannt von: EDGETRANSPORT.EXE.


Zunächst dachte ich, dass wäre bedingt dadurch, dass ich das Rollup eingespielt hatte und deshalb die Dienste logischer Weise beendet werden mussten. Später erhielt ich jedoch diese Benachrichtung noch mehrmals. Im Ereignisprotokoll sieht man dazu folgenden Eintrag:

Posion Message

Sucht man etwas in der Suchmaschine seiner Wahl, so stösst man auf folgenden Beitrag:

http://social.technet.microsoft.com/Forums/fr-FR/exchange2010/thread/851f5687-7c58-4114-9369-7a5ad1e7aff1

Es sieht danach aus, dass das Problem durch die Transportregel verursacht wird, die den ausgehenden Disclaimer anfügt. In manchen fällten kann man sich behelfen, wenn man am Ende die Zeichenfolge &#12288; anfügt. Sollte dies nicht helfen, so bleibt einem nur übrig das Rollup 1 für SP3 wieder zu deinstallieren.

In jedem Fall sollte man einen Call bei Microsoft eröffnen, damit das Problem ausgiebig untersucht und schnell Abhilfe geschaffen werden kann.

Update 14.08.2013: Seit heute ist das Rollup 2 für Exchange 2010 SP3 verfügbar. Dies enthält den Hotfix http://support.microsoft.com/?id=2859596, welcher das Problem löst.

 

0