Montag, 29. Oktober 2012

Using Eseutil /MH - How to check which Transaction log files are not committed


You have been busy and have not had the time to check your backups recently, all of a sudden your all of the Exchange Databases go offline, after some investigation you realise your full backup has not ran for several weeks and the drive that houses these transaction logs is now full. This is an extremely common issue, and I see it in the real world on a regular basis, a lot often than I should.
We are lucky as the quickest and easiest way to get your Storage Group and its Information Stores back online is to move the committed Exchange Transaction Logs files to another location.
How do I know which Transaction log files aren’t committed?
One of the features of Eseutil is its ability to read the header information of an Exchange Database or a Checkpoint file to give you various information including the transaction log files that have not yet been committed.
How to read the Log Required value of an MDB or STM file
 In order to read the header information for each edb and stm file in the storage group that has stopped, but as your Database file/s have become dismounted because of a full volume, this is not an issue. The command to show the Log Required value is:
Eseutil /MH <database_name>
Performing this command will display the header information similar to shown in figure 1 below:
Figure 1: The Exchange Database header information
From the Example in Figure 1 the Log Required Value is 0-0 which basically means my database is in a clean shutdown state and all log files are committed. This value specifies the log files required for the Exchange Database to mount and means if the value of Log Required was anything other than 0-0, you can move log files that are lower than the lowest value of this field.
In any version of Exchange Pre Exchange 2003 SP1 you will need to convert this decimal value to a Hexadecimal value but with Eseutil from Exchange 2003 SP1 and above this value will already be in Hexadecimal.
You should never move the latest log file as this will prevent log files from being played back in a recovery scenario. This rule should always be followed even if the databases are in a clean shutdown state.

TIP:
You can find the location of your Exchange mdb and stm files by Opening the Exchange Administrator in Exchange 2003 server and navigating to:

 Servers |  | First Storage Group
> | Right click on the dismounted Information Store selecting Properties and click on the Database Tab

You can now simply copy and paste the Exchange Database location into the command line saving you typing


It is highly recommended that you perform a full backup after this procedure; if this backup is successful you can safely delete the transaction log files that were moved.

Netdom Examples

NetDom is a command-line tool that is built into Windows Server 2008. It is available if you have the Active Directory Domain Services (AD DS) server role installed. To use NetDom, you must run the NetDom command from an elevated command prompt. To open an elevated command prompt, click Start, right-click Command Prompt, and then click Run as administrator.

You can use NetDom to:
- Join a computer that runs Windows XP Professional or Windows Vista to a Windows Server 2008 or Windows Server 2003 or Windows 2000 or Windows NT 4.0 domain.
- Provide an option to specify the organizational unit (OU) for the computer account.
- Generate a random computer password for an initial Join operation.
- Manage computer accounts for domain member workstations and member servers. Management operations include:
- Add, Remove, Query.
- An option to specify the OU for the computer account.
- An option to move an existing computer account for a member workstation from one domain to another while maintaining the security descriptor on the computer account.
- Establish one-way or two-way trust relationships between domains, including the following kinds of trust relationships:
- From a Windows 2000 or Windows Server 2003 or Windows Server 2008 domain to a Windows NT 4.0 domain.
- From a Windows 2000 or Windows Server 2003 or Windows Server 2008 domain to a Windows 2000 or Windows Server 2003 or Windows Server 2008 domain in another enterprise.
- Between two Windows 2000 or Windows Server 2003 or Windows Server 2008 domains in an enterprise (a shortcut trust).
- The Windows Server 2008 or Windows Server 2003 or Windows 2000 Server half of an interoperable Kerberos protocol realm.
- Verify or reset the secure channel for the following configurations:
- Member workstations and servers.
- Backup domain controllers (BDCs) in a Windows NT 4.0 domain.
- Specific Windows Server 2008 or Windows Server 2003 or Windows 2000 replicas.
- Manage trust relationships between domains, including the following operations:
- Enumerate trust relationships (direct and indirect).
- View and change some attributes on a trust.
NetDom Commands
Here are the NetDom commands.
Command
Description
Netdom addAdds a workstation or server account to the domain.
Netdom computernameManages the primary and alternate names for a computer. This command can safely rename Active Directory domain controllers as well as member servers.
Netdom joinJoins a workstation or member server to a domain. The act of joining a computer to a domain creates an account for the computer on the domain, if it does not already exist.
Netdom moveMoves a workstation or member server to a new domain. The act of moving a computer to a new domain creates an account for the computer on the domain, if it does not already exist.
Netdom queryQueries the domain for information such as membership and trust.
Netdom removeRemoves a workstation or server from the domain.
Netdom movent4bdcRenames a Windows NT 4.0 backup domain controller to reflect a domain name change. This can assist in Windows NT 4.0 domain renaming efforts.
Netdom renamecomputerRenames a domain computer and its corresponding domain account. Use this command to rename domain workstations and member servers only. To rename domain controllers, use thenetdom computername command.
Netdom resetResets the secure connection between a workstation and a domain controller.
Netdom resetpwdResets the computer account password for a domain controller.
Netdom trustEstablishes, verifies, or resets a trust relationship between domains.
Netdom verifyVerifies the secure connection between a workstation and a domain controller.
Microsoft has listed lots of examples on TechNet here. Here are some of them.
NetDom Examples
NOTE: The following examples apply to at least Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1 and Windows Server 2003 with SP2.
Example 1: Add a Workstation or Member Server to a Windows NT 4.0 Domain
To add the workstation mywksta to the Windows NT 4.0 domainreskita, type the following at the command line:
netdom add /d:reskita mywksta /ud:mydomain\admin /pd:password
Example 2: Add a Workstation or Member Server to a Windows Server 2003 Domain
To add the workstation mywksta to the Windows Server 2003 domain devgroup.example.com in the organizational unit (OU) Dsys/workstations, type the following at the command prompt:
netdom add/d:devgroup.example.com mywksta /OU:OU=Dsys,OU=Workstations,DC=microsoft,DC=com
Note
  • If the /ou parameter is not specified, the account is created in the Computers container.
Example 3: Move a Windows NT 4.0 BDC to a new domain
To join myBDC to the Windows NT 4.0 domain reskita type the following at the command prompt:
netdom mybdc moveNT4BDC /domain:reskita
Example 4: Add an alternate name for a Windows Server 2003 domain controller
To give an alternate name for the domain controller DC in the example.com domain, use the following syntax:
netdom computername dc /add:altDC.example.com
A name must first exist as an alternate before it can be made the primary name of a computer.
Example 5: Rename a domain controller in a Windows Server 2003 domain
To rename the domain controller DC to altDC in the example.com domain use the following syntax:
netdom computername dc /makeprimary:altdc.example.com
To rename a member server you must choose one of the existing alternate names for the computer and make it the new primary name.
Example 6: Rename a Member Server
To rename the member server member to member1, type the following at the command prompt:
netdom renamecomputer member /newname:member1.example.com /userd:administrator
Example 7: Join a Workstation or Member Server to a Domain
To join mywksta to the devgroup.example.com domain in the Dsys/workstations organizational unit, type the following at the command prompt:
netdom join /d:devgroup.example.com mywksta /OU:OU=Dsys,OU=Workstations,DC=microsoft,DC=com
Besides adding the computer account to the domain, the workstation is modified to contain the appropriate shared secret to complete the join operation.
Example 8: Remove a Workstation or Member Server from a Domain
To remove mywksta from the mydomain domain and make the workstation a part of a workgroup, type the following at the command prompt:
netdom remove /d:mydomain mywksta /ud:mydomain\admin /pd:password
Example 9: Move a Workstation or Member Server from One Domain to Another
To move mywksta from its current domain into the mydomain domain, type the following at the command prompt:
netdom move /d:mydomain mywksta /ud:mydomain\admin /pd:password
If the destination is a Windows 2000 domain, the Security ID history (SIDHistory) for the workstation is updated, retaining the security permissions that the computer account had previously.
Example 10: Reset the secure channel for a workstation, member server, or Windows NT 4.0 BDC
To reset the secure channel secret maintained between mywksta and devgroup.example.com (regardless of OU), type the following at the command prompt:
netdom reset /d:devgroup.example.com mywksta
To reset the secure channel between the Windows NT 4.0 PDC for Northamerica and the backup domain controller NABDC, type the following at the command prompt:
netdom reset /d:Northamerica NABDC
Example 11: Force a Secure Channel Session Between a Member and a Specific Domain Controller
Members often establish secure channel sessions with non-local domain controllers. To force a secure channel session between a member and a specific domain controller by using the /server parameter with the reset operation, type the following at the command prompt:
netdom reset /d:devgroup.example.com mywksta /Server:mylocalbdc
Example 12: Verify a Workstation or Member Server Secure Channel
To verify the secure channel secret is maintained between mywksta and devgroup.example.com, type the following at the command prompt:
netdom verify /d:devgroup.example.com mywksta
Example 13: Establish a One-Way Trust Relationship
When used with the trust operation, the /d:Domain parameter always refers to the trusted domain.
To set the Windows NT 4.0 resource domain USA-Chicago to trust the Windows NT 4.0 account domain Northamerica, type the following at the command prompt:
netdom trust /d:Northamerica USA-Chicago /add /Ud:Northamerica\admin /Pd:* /Uo:USA-Chicago\admin /Po:*
Press Enter and the following prompt is displayed:
Password for Northamerica\admin:
Enter the password for Northamerica\admin and press Enter. The following prompt is displayed:
Password for USA-Chicago\admin:
Enter the password for USA-Chicago\admin and press Enter.
The user must have credentials for both domains. The /pd parameter can be used to specify the password for Northamerica\admin and the /po parameter can be used to specify the password for USA-Chicago\admin. If passwords are not provided on the command line, the user is prompted for both.
If you then want to specify a two-way trust, type the following at the command prompt
netdom trust /d:marketing.example.com engineering.example.com /add /twoway /Uo:admin@engineering.example.com /Ud:admin@marketing.example.com:
Example 14: Establish a One-Way Trust Relationship from a Windows Domain to a Non-Windows Kerberos Realm
To establish a one-way trust where Northamerica trusts the non-Windows Kerberos realm ATHENA, type the following at the command prompt:
netdom trust /d:ATHENA Northamerica /add /PT:password /realm
The /d parameter specifies the trusted domain and the /realm parameter indicates that this is a non-Windows Kerberos realm. The order of the domains is not important. Credentials to the Windows 2000 domain can be supplied if needed.
Note
  • Verifying a specific trust relationship requires credentials unless the user has domain administrator privileges on both domains.
If you want to set the Kerberos realm ATHENA to trust the Northamerica domain, type the following at the command prompt:
netdom trust /d:Northamerica ATHENA /add
Note
  • To make the trust two-way, you can specify the /twoway parameter.
Non-Windows Kerberos trusts are created as non-transitive. If you want to change the trust from ATHENA to Northamerica as transitive, type the following at the command prompt:
netdom trust Northamerica /d:ATHENA /trans:yes
To display the transitive state, type the following at the command prompt:
netdom trust Northamerica /d:ATHENA /trans
The order of the two domains above is not important. Either can be the non-Windows Kerberos domain.
Example 15: Break a One-Way Trust Relationship
To undo the trust that USA-Chicago has for Northamerica, type the following at the command prompt:
netdom trust /d:Northamerica USA-Chicago /remove
Example 16: Break a Two-Way Trust Relationship
To break a two-way trust relationship, type the following at the command prompt:
netdom trust /d:marketing.example.com Engineering.example.com /remove /twoway /Uo:admin@engineering.example.com /Ud:admin@marketing.example.com
Example 17: Verify a Specific Trust Relationship
To verify the one-way trust that USA-Chicago has for Northamerica, type the following at the command prompt:
netdom trust /d:Northamerica USA-Chicago /verify
To verify a two-way trust between the Northamerica and Europe domains, type the following at the command prompt:
netdom trust /d:Northamerica EUROPE /verify /twoway
The /verify parameter checks that the appropriate shared secrets are synchronized between the two items involved in the trust.
Example 18: Reset a Specific Trust Relationship
To reset the secure channel for the one-way trust between Northamerica and USA-Chicago, type the following at the command prompt:
netdom trust /d:Northamerica USA-Chicago /Ud:Northamerica\admin /reset
The /reset parameter synchronizes the appropriate shared secrets if they are not already synchronized.
Example 19: Verify Kerberos Functionality
To verify Kerberos authentication between a workstation and a service located in the domain devgroup.example.com, type the following at the command prompt:
netdom trust /d:devgroup.example.com /verify /KERBEROS
When you use the NetDom trust operation with the /verify /kerberos parameters, it seeks a session ticket for the Kerberos Admin service in the target domain. If successful, you can conclude that all Kerberos operations (for example KDC referrals) are operating correctly between the workstation and the target domain.
Note
  • This operation cannot be executed remotely. It must be run on the workstation being tested.
Example 20: View All Workstation Members in a Domain
To list all the workstations in the domain Northamerica, type the following at the command prompt:
netdom query /d:Northamerica WORKSTATION
Example 21: View All Server Members in a Domain
To list all of the servers in Northamerica, type the following at the command prompt:
netdom query /d:Northamerica SERVER
Example 22: View All Domain Controller Members in a Domain
To list all the domain controllers in the domain Northamerica, type the following at the command prompt:
netdom query /d:Northamerica DC
Example 23: View All Organizational Unit Members in a Domain
To list all of the OUs in devgroup.example.com, type the following at the command prompt:
netdom query /d:devgroup.example.com OU
Example 24: List the Primary Domain Controller Member in a Domain
To list the PDC for Northamerica, type the following at the command prompt:
netdom query /d:Northamerica PDC
Example 25: List the Primary Domain Controller Emulator in a Domain
To list the current PDC emulator for devgroup.example.com, type the following at the command prompt:
netdom query /d:devgroup.example.com FSMO
NOTE: There are more examples on TechNet here.

Freitag, 4. Mai 2012

MySQL Zweiseitige - Replikation umsetzten

Wir gehen davon aus, wir hätten zwei identische Suse Linux Server, auf denen MySql läuft.
Es sind masterserver.firma.de und slaveserver.firma.de
Eigentlich sind aber beide master und slave gleichzeitig. Die Datenbank Inhalte beider Server sind jederzeit (JEDERZEIT) absolut identisch. Sobald auf einem der Server ein neuer Datenbank Eintrag gemacht wird, wird er sofort repliziert auf den jeweils anderen.
Wir gehen davon aus, dass auf beiden Servern in der /etc/my.cnf folgende Einträge drinstehen

masterserver.firma.de

log-bin
server-id = 1
master-host = 192.168.0.2
master-user = repl
master-password = GeHe!mReplik@ntP@sswort
log-slave-updates

slaveserver.firma.de

log-bin
server-id = 2
master-host = 192.168.0.1
master-user = repl
master-password = GeHe!mReplik@ntP@sswort
log-slave-updates

Wir gehen davon aus, dass auf beiden Servern ein mysql-User namens „repl“ angelegt ist, der das FILE Recht hat.
Die beiden Server sind übrigens mit per Crossoverkabel verbunden auf dem zweiten Netzwerkinterface und haben private IP-Adressen. Diese Verbindung dient nur zur Replikation der Datenbanken.

Folgende Anleitung hilft, die Replikation aufzusetzen bzw. eine defekte Replikation binnen 10 Minuten zu reparieren - also quasi noch vor der Mittagspause!

1. Auf beiden Servern mysql beenden

/etc/init.d/mysql Stop


2. Auf slaveserver.firma.de den Ordner /var/lib/mysql umbenennen mit

mv /var/lib/mysql /var/lib/mysql.original

3. binäres Loggen auf BEIDEN deaktivieren mit

vi /etc/my.cnf

in der my.cnf auf beiden Servern folgende Eintraege auskommentieren (# davorstellen)

log-bin (Zeile 47)
log-slave-updates (Zeile 56)

4. Auf Server masterserver.firma.de im Ordner /var/lib/mysql alles löschen, das mit „www-*“ beginnt (das sind die „alten“ bin-log-Dateien, die wir loswerden müssen) (ps. das "www-*" bezieht sich auf MEINE Server. Bei dir heissen sie so, wie der Server heisst, also "masterserver-*")
Ferner loeschen wir die Dateien „master.info“ sowie „relay-log.info“

cd /var/lib/mysql
rm www-*
rm master.info
rm relay-log.info

5. Jetzt auf masterserver.firma.de vom Ordner /var/lib/mysql ein „tgz“ Paket erstellen
cd /
tar czvf mysql.tgz /var/lib/mysql

6. Die Datei mysql.tgz kopieren von masterserver.firma.de nach slaveserver.firma.de mit

scp mysql.tgz root@slaveserver.firma.de:/

7. Auf slaveserver.firma.de das kopierte File extrahieren

cd /
tar xzvf mysql.tgz

Nun sind die Verzeichnisse /var/lib/mysql auf beiden Servern exakt gleich.

8. Auf beiden Servern den mysql Dienst starten und wieder stoppen

/etc/init.d/mysql start
/etc/init.d/mysql Stop


9. Auf beiden Servern binäres Loggen wieder aktivieren

vi /etc/my.cnf

Das Kommentarzeichen # wieder entfernen von den Einträgen

bin-log (Zeile 47)
log-slave-updates (Zeile 56)

10. Auf beiden Servern mysql Dienst wieder starten

/etc/init.d/mysql start


Nun sind beide MySql Datenbanken gleich und die Replikation müsste funktionieren.

mysql Logdatei kontrollieren

tail -100 /var/lib/mysql/mysqld.log

Verändern der Zeitzone in Linux

Verändern der Zeitzone in Linux
Wenn die Zeitzone nicht stimmt, wird ntp zwar ordnungsgemäß arbeiten, 
aber man wundert sich dass die Uhrzeit nicht stimmt.

Mit diesem Befehl kann man die Zeitzone neu setzen
$ sudo dpkg-reconfigure tzdata

Mit diesem Befehl bekommt man die Zeitzone herau
$ cat /etc/timezone
Europe/Berlin

mplayer.exe CONVERT

mplayer.exe -ao pcm -vo null -dumpfile output.wav input.avi


Monitoring ESXi and HP Hardware with Nagios/Icinga

All of you might be aware of VMWare ESXi, VMWares powerful and free Hypervisor with 64-bit architecture.
Unfortunately most of the monitoring features from the licensed (and expensive) full version are missing – SNMP gets aren’t possible either, only traps. But there is a way out of this drawback, at least if you’re using HP hardware (should work with G5+) and nagios/icinga as monitoring tool.

First of all the best way to use ESXi on HP hardware is by instaling the ESXi version supplied by HP which can be downloaded here for free. In this version all needed agents and tools in order to monitor the ESXi server with nagios/icinga are already included.
For those who want to upgrade their existing ESXi server(s) HP offers its ESXi bundle as additional ESXi patch (hp-esxi4.0uX-bundle-1.2.zip), download here. In order to deploy it onto the ESXi servers the VMware vSphere CLI is needed, could be obtained from here.
After installing all the prequisites you have to deploy the ESXi bundle to your server. If you`re using a Windows client the command line, called from \bin directory of your vSphere Cli Installation (e.g. C:\Program Files\VMware\VMware vSphere CLI\bin), just use:
vihostupdate.pl –server –install –bundle c:\hp-esxi4.0uX-bundle-1.2.zip
After the next reboot of your server (unfortunately a reboot is necessary) you should be able to find new monitoring sensors in the configuration tab of your vSphere client as shown in the screenshot, e.g. the disk status:



If this works fine we continue with the next step: Monitoring multiple ESXi Servers with nagios/icinga
There are mulitiple versions of the python script check_esx_wbem.py in the net, but only some of them work properly with HP Hardware. (there is also a version which should be working with hardware from dell )
Requirements for the script are Python 2.6 and the Python extension pywbem.
The script we are using has proofed its functionality several times, you can obtain it
from here or directly from my site here.

Command usage is:
Command: python $USER1$/check_esxi_wbem.py https://$HOSTADDRESS$:5989 $ARG1$ $ARG2$ $ARG3$
example error would look like this:
/libexec # python check_esx_wbem.py https://vmware42.google.dmz:5989 statistics password hp
CRITICAL : Disk 4 on HPSA1 : Port 1I Box 1 Bay 4 : 136GB : Data Disk : Disk Error
if everything is fine:
/libexec # python check_esx_wbem.py https://vmware00.microsoft.dmz:5989 statistics password hp
OK hp hardware
Links:
Download ESXi version supplied by HP
HP ESXi Offline Bundle
VMware vSphere CLI
checK-esxi_wbem.py download

Freitag, 9. März 2012

Lazy man's way to track user logon/logoff

I always like to find easy ways to do things. Mick recently shared in the public newsgroup how he maintains a log file of user's logons and logoffs.

Step 1: Create the following two files using Notepad or your favorite text editor:

------logon.cmd----
echo logon %username% %computername% %date% %time% >> \\sbs\share\logon.log

-----logoff.cmd-----
echo logoff %username% %computername% %date% %time% >> \\sbs\share\logon.log

Step 2: Update Group Policy to run the appropriate batch file. In Group Policy, go to:
User Configuration-> Windows Settings-> Scripts (Logon/Logoff)-> Logon

Step 3: As users log on and off, your log file should look something like this:

logon June VSXP Tue 22/02/2005 10:39:51.12
logoff June VSXP Tue 22/02/2005 10:41:08.45
logon MickM VSXP Tue 22/02/2005 10:42:01.07
logoff MickM VSXP Tue 22/02/2005 10:42:46.81