Wenn man auf einem Windows Server das Dedup-Feature einschaltet kann es passieren, dass der ChunkStore (dieser befindet sich in dem Ordner „System Volume Information“) in dem die Informationen für das Dedup gespeichert werden immer weiter wächst und so riesig wird das er teilweise den ganzen freien Platz auf dem Volume verbraucht.

Das kann man aber über einen DedupJob aber wieder fixen -hier am Beispiel eines Volumes F: :

eine Powershell als Administrator öffnen

und

Start-DedupJob -Volume “F:” -Type GarbageCollection -Memory 50

man kann mit

Get-DedupJob

überprüfen wie weit der Job schon ist.

Hilft dies nicht ist eine Möglichkeit noch die Deduplizierung rückgänging zu machen.

Dazu lässt man Dedup auf dem Volume aktiviert – deaktiviert aber die Hintergrundaktivität

Set-DedupSchedule BackgroundOptimization -enable $false

Start-DedupJob -Volume „F:“ -Type Unoptimization

Start-DedupJob -Volume “F:” -Type GarbageCollection

danach sollte der Chunk-Ordner weg sein – dann kann dedup bei Bedarf wieder aktiviert werden.

Auf einem Windows-Server (in dem Fall ein 2008 R2) mit IIS starteten die IIS-Dienste nicht, da der Windows-Prozessaktivierungsdienst mit folgender Fehlermeldung nicht starten wollte:

„Windows konnte den Prozessaktivierungsdienst nicht sarten – Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren“

bzw.:

„Windows could not start the Windows Process Activation Service – Error 6801: Transaction support within the specified resource manager is not started or was shut down due to an error“

Das Problem kann man folgend lösen:

eine Eingabeaufforderung (cmd) als Administrator startet und folgenden Befehl ausführen:

fsutil resource setautoreset true c:\

Danach muss man den Server neu starten – jetzt sollte der WAS (Windows-Prozessaktivierungsdienst) wieder starten – und somit auch die davon abhängigen IIS-Dienste 🙂

Quelle: forum.iis.net

Manchmal muss man unter Windows ein Programm oder ein Skript mit speziellen Credentials ausführen und zusätzlich „als Administrator“ ausführen.

Das funktioniert über die Powershell einfach wie folgt:

$User = "Username"
$Password = "Password" | ConvertTo-SecureString -asPlainText -Force
$MyCredential = New-Object System.Management.Automation.PSCredential($User,$Password)

Start-Process -WindowStyle Hidden powershell.exe -Credential $MyCredential -ArgumentList '-noprofile -command &{Start c:\program\program.exe -Verb RunAs}'

Hier wird eine Powershell.exe mit den angegebenen Username und Passwort ausgeführt (Klartext-Passwörter sind natürlich schlecht – dienen hier nur als Beispiel!) und der Powershell.exe wird das Programm zum ausführen übergeben mit dem Attribut -Verb RunAs dass das Programm „als Administrator“ ausführt.

fertig 🙂

Ich habe meine WordPress-Installation auf einen neuen Server umgezogen – inklusive upgrade der Software -> neueste Ubuntu-Version, MariaDB statt MySQL, PHP7 statt PHP5, neueste nginx-Version inkl. benutztung von neuen Features, etc…

Es sollte alles funktionieren – falls nicht bitte hier einen kurzen Kommentar rein – Danke 🙂

Sehr oft muss ich per Telnet Emails verschicken – meistens aus Testzwecken bei Exchange oder auch anderen Mailserver-Installationen. Hier mal einen kleine Anleitung wie das geht:

Beispiel: Ich komme von einer freigegebenen IP (ohne Authentifikation) und will mit test@mail.local eine Email an an test@mail.extern versenden. (Die Befehle und Eingaben sind hervorgehoben- die Antworten des Servers normal)

In der Konsole sieht das so aus:

telnet exchange.mail.local 25
220 exchange.mail.local Microsoft ESMTP MAIL Service ready at Sun, 23 Feb 2014 08:49:36 -0700
helo mail.local
250 host.local Hello [10.26.115.13]
mail from:test@mail.local
250 2.1.0 Sender OK
rcpt to:test@mail.extern
250 2.1.5 Recipient OK
data
354 Start mail input; end with < CRLF >.< CRLF >
From: Mein Anzeigename
To: Empfänger Anzeigename
Subject:Testemail mit Telnet

Inhalt der Testmail.
.

250 2.6.0 <8c642f92-e0e3-4c9e-b3d3-21054eed3244@exchange.domain.com> Queued mail for delivery
quit
221 2.0.0 Service closing transmission channel
Connection to host lost.

Somit haben wir die Email verschickt. Wie oben schon angedeutet funktioniert das versenden ohne Authentifikation nur von IP-Adressen die auf dem Exchange, Postfix etc. auch explizit für das mailen ohne Authentifzierung (Relay) freigegeben worden sind – wie für Exchange hier beschrieben 🙂

Die Fujitsu Eternus DX Storages kommen im Auslieferungszustand mit folgenden Logins:

User: root
Password: root

User: f.ce
Password: < Checkcode >< Serialnumber >

Der Checkcode ist eine 2-Buchstaben-Kennung (z.B. FD), die auf der Gehäuserückseite aufgeklebt ist. Die Seriennummer ist die 10-stellige Kombination aus Zahlen und Ziffern, die normalerweise mit einem Y beginnt und auch im Webinterface angezeigt wird. Der Checkcode muss in Großbuchstaben angeben werden, so das z.B. aus dem Checkcode „FD“ und der Seriennummer „YALK000123“ das Kennwort FDYALK000123 ensteht.

Das Root-Kennwort sollte unbedingt geändert werden. Ich lasse jedoch meistens das f.ce-Kennwort in dieser Kombination, damit ich einen Fallback-Admin habe, falls man mal das Root-Kennwort vergisst 😉

Quelle: Fujitsu Eternus DX60/80 S1 WebGUI-User-Guide und elasticsky.de

Ich hatte das Problem das sich in einer Umgebung mit VMWare View der vCenter-Server geändert hat. Ich habe versucht eine Anleitung für einen Umzug zu finden – leider ohne großen Erfolg. Hier wie ich es trotzdem hinbekommen habe:

Ausgangslage: VMWare View 5.1 auf eigenem Server intalliert. Desktop-Pools sind keine Linked-Clones. Neuer vCenter-Server installiert,die ESXi-Host verbunden und konfiguriert.

Problem: VMWare View kann zwar mehrere vCenter verwalten – aber die Desktop-Pools können nur einem vCenter zugeordnet sein – und das lässt sich nicht ändern. Also muss man hier ein wenig nachhelfen.

Dazu führt man auf dem View-Server folgende Schritte durch:

1) vCenter in View Manager eintragen

Als erstes muss der neue vCenter im View Manager eingetragen werden. Dazu navigiert man zu
View Konfiguration -> Server -> vCenter Server und fügt über Hinzufügen
mit Hilfe des Assistenten den neuen Server hinzu.

Dadurch wird im View LDAP das Objekt für den neuen vCenter angelegt.

2) Export der Einstellungen

Auch die ganzen Pool-Einstellungen stehen in diesem LDAP. Wir öffnen die VMWare PowerCLI Powershell und machen einen Export

vdmexport -v -f c:\view-export.ldif

3) Anpassen der Einstellungen

Als erstes rate ich dazu ein Backup der Datei zu erstellen. Danach können wir durch ersetzen der alten vCenter-ID durch die neue vCenter-ID die Konfiguration der Desktop-Pools anpassen.

Dazu öffnen wir die Datei in einem Editor – ich empfehle Notepad oder Notepad++.

Zuerst muss man die vCenter-Definitionen in der Datei suchen. Sie sehen so aus:

Der alte vCenter:

dn: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: abcd1234-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://alter-vCenter.test.local:443/sdk

Der neue vCenter

dn: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
changetype: add
objectClass: pae-PropertyObject
objectClass: pae-VirtualCenter
cn: efgh5678-49cb-4fce-ae39-5dbcba9120d1
pae-VCCreateRampFactor: 20
pae-VCUserName: root
pae-SVIUserPassword: {SSO-AES:1}ir+/2x2x2x2x2x2x2xx2x2x2x
pae-VCURL: https://neuer-vCenter.test.local:443/sdk

Der dn-Wert ist die ID des vCenters – in diesem Fall von unserem neuen Server also efgh5678-49cb-4fce-ae39-5dbcba9120d1.

Jetzt sucht man nach dem pae-VCDN-Wert der Desktop-Pools. Dafür sucht man mit der alten ID nach

pae-VCDN: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1

Hier müsste man die einzelnen Desktop-Pools finden. Jetzt kann man die ID einfach ersetzten.

Suchen nach:
pae-VCDN: CN=abcd1234-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int
Ersetzten durch:
pae-VCDN: CN=efgh5678-49cb-4fce-ae39-5dbcba9120d1,OU=VirtualCenter,OU=Properties,DC=vdi,DC=vmware,DC=int

Ich empfehle hier keine „Alle Erstzen“ des Editors zu machen, sonder schön einzeln und manuell.

Danach speichern wir die Datei am besten unter c:\view-import.ldif ab.

4) Import der Einstellungen

Wir öffnen wieder die VMWare PowerCLI Powershell und machen den Import

vdmimport -f c:\view-import.ldif

Der Import ändern normalerweise nur Werte die geändert worden sind.

Danach im VMWare View Manager die Pools überprüfen – nach einem Browser-Refresh müssten die Pools den neuen vCenter-Server anzeigen.

Falls möglich jetzt noch den alten vCenter (wenn nicht eh schon) beenden und testen. Bei mir traten keine Probleme auf.

Das wars 🙂

Quelle: Link

Ich bin von Blogger.com / Blogspot auf eine von mir selbst gehostete WordPress-Installation umgezogen.

Dies hatte mehrere Gründe, z. B. waren die neuen Themes von Google (DynamicViews) zwar wenigstens mal ein bischen modern – leider hatte sie keine Möglichkeit Einfluss auf die Seite zu nehmen – so lies sich die Werbung nicht ausblenden, etc..

Und natürlich auch ein wenig  das ich jetzt kompletten Zugriff hab .-)

Geholfen beim Umzug hat mir http://blogger2wordpress.appspot.com. Damit liesen sich die von Blogger exportierten Daten konvertieren und in WordPress importieren – inklusive Kommentare, etc.

 

 

 

Will man, z. B. für ein Login-Script oder in einer Batch (oder einfach auf der Kommandozeile), rausfinden, ob ein Benutzer in einer bestimmten Gruppe ist hat man ja „früher“ gern die ifmember.exe aus den Windows 2003 ResouceKit Tools (Link) benutzt.

Doch leider funktioniert diese unter Windows Vista / 7 / 2008 / 2008 R2 nicht mehr (wegen dem UAC).

Hier kann man Bordmittel benutzen die in allen Windows-Vesionen funktioniert.

Hat man früher mit ifmember.exe folgendes gemacht:

ifmember Verwaltung
if errorlevel = 1 (
net use v: \\server\Verwaltung /persistent:yes
)

macht man jetzt einfach:

net user /DOMAIN %username% | find „Verwaltung“
if not errorlevel = 1 (
net use v: \\server\Verwaltung /persistent:yes
)

Funktioniert wunderbar!

TIPP: ein net user /DOMAIN %username% in der CMD zeigt alle Gruppenmitgliedschaften des Benutzers im ActiveDirectory an. So bekommt man schnell einen Überblick, in welcher Gruppe der Benutzer ist – oder nicht 😉

Wenn man sich an einer Oracle-Datenbank anmelden will und folgenden Fehler bekommt:

ERROR:
ORA-28000: the account is locked

dann ist der Account gesperrt.
Den kann man ganz einfach wieder entsperren. Anmelden mit einen User mit genügend Rechten (oder mit dem sysdba) und folgendes ausführen:

alter user username account unlock;

Man kann natürlich genau so einen User sperren:

alter user username account lock;

Tipp: Um den Status eines Benutzer anzeigen zu lassen, kann man mittels

select USERNAME,ACCOUNT_STATUS,LOCK_DATE from dba_users where USERNAME=’Test’;

Damit erhält man eine Ausgabe, die wie folgt aussieht:

USERNAME ACCOUNT_STATUS LOCK_DATE
—————————————————————
Test              LOCKED                    14-OCT-10

So hat man einen kleinen Überblick über den Status des Users und seit wann der User gesperrt ist.