Friday, July 30, 2010

Baidu vs Google

Today I have decided to compare Google and Baidu and to see if there is any cultural difference that can be spotted through the comparions of an American and A Chinese search engine.

The keywords I've choosen are: Unesco, Freedom, Peace, USA, China, Obama, Sarkozy, Berlusconi, Tibet, Free Tibet, Stop War, Iran, Afghanistan, Microsoft, Lukashenko, Leisure Travel, Sex, Bruce Willis, Arnold Schwarzenegger, Jackie Chan, Bruce Lee, Powershell

Here's the result:

For sake of democracy, I have searched every word on baidu in its English form and its translated Cantonese form.

The result are at first view quite stunning, as Google gives you much more addresses for any (but Jackie Chan!!) search keyword that its Chinese concurrent.

Furthermore, I have decided to put into account the enormous difference between people speaking English as a first language and people speaaking any form of Chinese as a first language.

These are the numbers, found on Wikipedia:
People speaking english as first language: 331 000 000
People speaking chinese as first language: 1 300 000 000

So one billion more people on earth speak Chinese as their first language!

This gives us a proportion Chinese/English of 3,9. If we take this into account, we see that Google brings you back much more result per person than Baidu in every field.

As a general analysis, we can see that Americans talk mainly about themselves (USA), about Sex, about China and don't really take into any account Soviet issues (Lukashenko), Arnold Schwarzenegger's movies and Freedom in Tibet.

Chinese instead talk about China and Microsoft the same number of times (50 millions), talk about Microsoft much more than they talk about Sex.... and prefer Jackie Chan's movies to Bruce Willis' ones!

Now the question is: why in China they talk so much about Microsoft? I have simply no idea.

Powershell script to search Active Directory for servers

$strFilter = "(&(objectCategory=computer)(operatingSystem=Windows*Server*))"

$objDomain = New-Object System.DirectoryServices.DirectoryEntry("LDAP://OU=ou_name,dc=company,dc=com")

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher

$objSearcher.SearchRoot = $objDomain

$objSearcher.PageSize = 1000

$objSearcher.Filter = $strFilter

$objSearcher.SearchScope = "Subtree"

$colProplist = "name"

foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()

foreach ($objResult in $colResults)

{$objItem = $objResult.Properties; $

Write-Output $ | Out-File file.txt -append


Powershell script to check scheduled tasks status

Function Get-ScheduledTask {



$tmpFile=Join-Path $env:temp "gsctmp.csv"

Write-Debug "Retrieving SCHTASKS.EXE for $computername"

$s=schtasks /query /s $computername /fo csv /v

if (-not $s)


Write-Debug "No connection to $computername"

Write-Warning ("Failed to find {0}" -f $computername.ToUpper())




if ($s -is [string])


Write-Debug "No scheduled tasks found for $computername"

Write-Warning ("{0} {1}" -f $computername.ToUpper(),$s)




Write-Debug "Sending data to $tmpFile"

$s[1..($s.count-1)] | Out-File $tmpFile -force

Write-Debug "Importing $tmpFile"

Import-Csv $tmpFile

Write-Debug "Deleting $tmpFile"

Remove-Item $tmpFile


get-content C:\PowerShellScripts\ScheduledTasks\serverlist.txt | foreach {get-scheduledtask $_ } | Select Hostname,Taskname,"Next Run Time","Last Run Time",Creator,"Run As User","Task To Run","Scheduled Task State","Scheduled Type",Schedule | Export-CSV C:\PowerShellScripts\ScheduledTasks\Report.CSV

How to connect to Internet and dowload a page with Powershell

This can't be any easier!


$wc= new-object System.Net.WebClient

$proxy = new-object System.Net.WebProxy ""

$proxy.Credentials = New-Object System.Net.NetworkCredential ("proxyusername", "proxypassword")

#$proxy.UseDefaultCredentials = $true



$oIE=new-object -com internetexplorer.application



Rogue DHCP

This is a wiki on how to disable DHCP Authorization.

1. Add the following DWORD value in the registry of the future DHCP server:

a. Start Registry Editor (Regedt32.exe).

b. Locate and click the following key in the registry:


c. On the Edit menu, click Add Value, and then add the following registry value:

Value name: DisableRogueDetection

Data type: REG_DWORD

Radix: Binary

Value data: (Hexadecimal) 1, which will be saved as 0x00000001

d. Quit Registry Editor.

2. After you have added the preceding value, restart the server for the setting to take effect. Ahhhh, Microsoft Windows always willing to restart... this is very sorry for one of the leading 2010 Operating Systems around!

Wanna earn money with blogs?

Today I decided to have a look at different possibilities to ad ads to my blog and see if I can earn a few bucks... so I went to my buddy Google and discovered that the main choice to make is to go for Adsense or not to go for Adsense. As far as I can understand, Adsense has improved a lot these years and ads publishsing has become a quite straightforward process anyone can apply to. The question now is, what are the other possibilites the ads market has to offer., because, as long as I can see, Adsense doesn't really bring a lot of money...

So, browsing a few blog, I found out that many webiste do offer ways and means of putting ads on a blog. Just to list the ones I found the most interesting, here's some links:

To me, Linkbucks is by far the most interesting solution, but you have to go through a quite complex (or confusing) procedure to understand what the different linkmuras, linkbb, linkwords mean... and I think it takes time to understand which proposition is better for your site. Furthermore you have to publish lot of code in your blog, whic can be difficult if you are enough skilled in jungling with html code, javascript and all that stuff....
So, shoud you feel baffled trying to understand linckbucks and trying to insert their code into your blogger page, be happy, you are not alone!
I will try these days to better understand the way it works and see if I can a decent enough article to mark for reviewing on SharedReviews or on Triond and will post again with a compared outcome of these solutions. If any.

Thursday, July 29, 2010

ESX and VLAN trunking

One importanty thing to know when administering VMWare ESX servers is that the virtual switches in ESX Server do support VLAN (IEEE 802.1Q) trunking (also called VLAN tagging). Using VLANs, VMWARE admins can leverage their network infrastructures with ESX Server.

I have just found this interesting white paper which provides an overview of VLAN concepts and benefits and illustrates three possible ESX Server and virtual machine VLAN configurations.

Example of VLAN tag (802.1Q) in Ethernet frame:

As you can see, 802.1Q does not actually encapsulate the original frame. Instead, it adds a 32-bit field between the source MAC address and the Type/Length fields of the original frame.

For knowing more, just refer to:

Deploy ILO user configuration on HP BLADES

To deploy user configuration to newly installed blades in a HP Bladesystem C700, just ssh the active onboard administrator and then run the following commands to add ILO account:

Hponcfg 1-16 << end_


<LOGIN USER_LOGIN="username" PASSWORD="anything">

<USER_INFO MODE="write">





<ADMIN_PRIV value ="Yes"/>

<REMOTE_CONS_PRIV value ="Yes"/>

<RESET_SERVER_PRIV value ="Yes"/>

<VIRTUAL_MEDIA_PRIV value ="Yes"/>

<CONFIG_ILO_PRIV value="Yes"/>






Doing so will push user configuration to all connected blades on the rack in a very quick way.

Thursday, July 22, 2010

Remote administration tools for Microsoft Windows

1. -[ Remote administration with MSRPC (Win32 legacy management APIs) ]-

1.1 Introduction

The traditional method to administer remote Windows systems is to use Win32 legacy management APIs.

These APIs can be easily identified because they take a server name as one oftheir parameters:

- when the server name is empty (NULL), the API operates on the local server

- when a server name is specified, the API operates on the specified remote server

For instance, all APIs with names starting with Net such as NetShareEnum() belong to this class of APIs.

When used to administer a remote server, these APIs use the MSRPC protocol (Microsoft implementation of the DCE RPC standard) with the SMB transport.

SMB is the core protocol of Windows networks and operates on both port 139/tcp and 445/tcp. When used as a transport for MSRPC, named pipes inside the IPC$ share are used as RPC services endpoints.

1.2 Windows administation tools using Win32 legacy management APIs

Well-known Windows administration tools use these APIs and, as a consequence, can operate either on a local or remote system. Examples of these tools include:

- Registry Editor: regedit.exe

- Computer Management MMC snapin (and included MMC snapins)

- Local Users and Groups MMC snapin

- Event Viewer MMC snapin

- Services MMC snapin

- Shared Folders MMC snapin

- Device Manager MMC snapin

- Certificates MMC snapin

- netsh command (-r option, Routing and Remote Access service must be

running on remote server)

MSRPC interfaces used by these APIs are detailed in the "RPC services listening on named pipes" section of our Windows network services internals paper:

Note: the winreg interface (access to Windows registry) is used by most Windows administration tools. Thus, the Remote Registry service must be started on systems that are administered with these tools.

Well-known third-party tools also rely on these APIs, such as tools included in SysInternals's pstools package ( ):

- psfile.exe (remote enumeration of opened files)

- pslist.exe (remote processes enumeration)

- psloggedon.exe (remote logon session enumeration)

- psloglist.exe (remote eventlog management)

- pspasswd.exe (remote user password management)

- psservice.exe (remote service management)

On Unix systems, the rpcclient tool (Samba-TNG and Samba projects) implements a subset of MSRPC interfaces used by these APIs.

1.3 SMB session management

Because these APIs use the SMB transport for MSRPC, the authentication is only implemented at the SMB level. Thus, an SMB session to the remote system is first established, usually with administrator credentials, before using remote administration tools.

When the remote system is in the same Windows domain as the local machine, the SMB session can be transparently established, for instance if the user is connected to the local system with domain administrator credentials (by the way, a bad habit and not recommended).

However, if you are connected with a local account or with an unprivileged domain account, it will be necessary to establish an SMB session to the remote system with alternate credentials.

For instance, to establish a remote SMB session with the local administrator on the remote system, the following command can be used:

C:\>net use \\server_name\IPC$ /u:administrator *

Then, the exact name specified in the previous command (\\server_name, where server_name can be the NetBIOS, DNS or IP address server name) must be specified as remote server name in administration tools.

It is possible to establish multiple SMB session to the same remote system with different credentials by using different server names in each case (the IP address in the first case, the NetBIOS name in the second case and the DNS name in the third case, if three concurrent sessions are needed).

The established SMB session will automatically be used and remote administration will be possible with the local administrator credentials of the remote system.

2. -[ Remote administration using WMI (Windows Management Instrumentation) ]-

2.1 Introduction

WMI (Windows Management Instrumentation) is the management framework available in recent Windows systems. WMI is built on the COM (Component Object Model) infrastructure and can thus operate remotely, using DCOM (Distributed COM).

WMI is frequently used by Windows administrators with VBS scripts. Many sample scripts are available at Microsoft Technet's Script Center:

In addition, several WMI-based administration tools are available by default on Windows systems to administer remote systems using WMI.

2.2 WMI-based administration tools

2.2.1 WMI Control MMC snapin

The WMI Control MMC snapin (wmimgmt.msc) is used to configure the WMI framework.

WMI settings can be configured on either a local or remote system, choosing Properties after clicking on the WMI Control icon.

In Windows 2000 and Windows XP, the WMI Control MMC snapin supports alternate credentials in the Change manager computer dialog box.

For Windows Server 2003, it is possible to use runas with the /netonly option to specify alternate credentials for mmc.exe (the WMI Control MMC snapin must then be added manually and the remote system name specified in the Another computer field):

C:\>runas /netonly /user:administrator mmc.exe

2.2.2 WMI tester (wbemtest.exe)

WMI tester (wbemtest.exe) is a tool available in all WMI implementations (Windows 2000, Windows XP and Windows Server 2003).

WMI tester is originally a WMI testing tool but it also makes an interesting WMI-based administration tool.

When started, wbemtest.exe displays a main window, with a Connect button at the top right.

The Connect window allows the specification of a WMI namespace. To connect to a remote system, the namespace must be prefixed with a UNC name, for instance:

Namespace: \\\root\cimv2

Alternate credentials can be specified in the Credentials fields (User, Password and Authority fields).

Once connected to a namespace, it is possible to:

- enumerate all WMI classes of the namespace, using the "Enum Classes" button with the Recursive option.

- enumerate instances of a given WMI class, using the "Enum Instances" button.

- execute a WQL query using the "Query" button, such as:

SELECT * FROM Win32_Process where name="lsass.exe"

- execute a method of a given instance, using the "Execute Method" button. The object path of the instance must be specified, such as:



2.2.3 WMIC (WMI command-line tool)

WMIC (wmic.exe) is installed by default on Windows XP and Windows Server 2003.

WMIC does not run on Windows 2000.

WMIC is typically used in interactive mode. The remote system name is specified with the /NODE option.

Alternate credentials can be used with the /USER and /PASSWORD options.

For instance, to connect to a remote system with IPv4 address with the local Administrator account, the following commands can be used:




Enter the password :********


BootDevice BuildNumber BuildType Caption

\Device\Harddisk0\Partition1 2195 Uniprocessor Free Microsoft Windows


Many different commands are supported by WMIC.

For more information, consult the presentation "WMIC: A New Approach to Managing Windows Infrastructure from a Command Line" available at .

2.2.4 winmsd.exe

In recent Windows systems, winmsd.exe has been replaced by the the msinfo32.exe program. However, winmsd.exe is in the system path whereas msinfo32.exe is not so it is easier to use winmsd.exe. winmsd.exe is a stub executable that starts msinfo32.exe.

winmsd.exe supports a "/computer" option, used to specify a remote system name.

When this option is used, the system configuration of the remote system is obtained using WMI and displayed by the program.

winmsd does not support alternate credentials and can not apparently be used with the /netonly option of runas.

2.3 Ports used by WMI

Because WMI relies on DCOM when used to connect to a remote server, access to TCP port 135 is required (IRemoteSCMActivator ORPC interface, also known as ISystemActivator). Then, a dynamic TCP port opened by the WMI service is used for WMI requests.

If a specific ports range for RPC services was configured on the remote server, ports dynamically allocated to DCOM servers are included in the range, including for the WMI service.

To configure a port range for RPC services, the rpccfg tool can be used, as documented in and .

3. -[ Remote administration with GUI-oriented tools ]-

Many Windows system administrators tend to use graphical remote administration tools that allow access to Windows GUI.

3.1 Terminal Services

Recent Windows systems (Windows 2000, Windows XP, Windows Server 2003) natively support Terminal Services, the feature of Windows NT that allow multiple concurrent interactive logon sessions. The network protocol used by Terminal Services is RDP (Remote Desktop Protocol) and operates by default on TCP port 3389.

Terminal Services relies on Windows authentication to authenticate users establishing remote sessions.

In addition, applicative permissions are supported by Terminal Services to restrict the category of users allowed to establish Terminal Services sessions (Permissions tab in the Properties of the RDP-Tcp transport in Terminal Services Configuration MMC snapin).

Windows XP and Windows Server 2003 also explictly support two new logon rights to either allow or deny Terminal Services sessions for different categories of users:

- Allow log on through Terminal Services

- Deny log on through Terminal Services

When used in Remote Administration mode in Windows 2000 and Windows Server 2003 (now called Remote Desktop for Administration), Terminal Services allows up to two concurrent sessions.

Windows XP and Windows Server 2003 include by default the Microsoft RDP client (mstsc.exe). It can be also be installed on Windows 2000 systems.

On Unix systems, the rdesktop program can be used ( ).

3.2 VNC, pcAnywhere, Dameware Mini Remote Control, ...

Remote administration tools such as VNC, pcAnywhere or Dameware Mini Remote Control are remote administration tools different from Terminal Services because these tools do not create logon sessions.

Instead, these tools remotely display the display of a remote system's console.

pcAnywhere and Dameware Mini Remote Control can use Windows authentication to authenticate remote users whereas VNC only supports password-based authentication.

These tools are typically used on systems that do not support Terminal Services (Windows NT 4.0 servers, Windows workstations).

On systems that support Terminal Services, it is recommended to use Terminal Services instead.

3.3 Dameware Mini Remote Control features

Dameware Mini Remote Control (DMRC) is frequently used because this tool has a remote installation feature that do not require prior installation on the remote system.

If not already installed, the Windows service used by DMRC is copied to the remote system using administrative shares and then installed and started, using MSRPC.

The different installation options must be considered carefully:

- Stop Service on Disconnect

- Remove Service on Disconnect

- Set Service Startup type to 'Manual' (default is 'Automatic')

By default, the service is installed on the remote system and set to startup automatically. Thus, once installed, it will remain available until manually removed by the system administrator.

To install the service the first time, local administrators credentials are required, as well as access to either TCP 445 or 139 (for SMB session establishment).

When started, the DMRC service opens TCP port 6129, used to establish the graphical remote session.

The DMRC client then connects to port 6129 and authenticates using Windows credentials (using either the Windows NT challenge/response mode or the Encrypted Windows logon mode).

If the account used to authenticate has local administrator credentials, access to the GUI of the remote system is allowed. For a non-administrator user, the "Permission required for these account types" access option (enabled by default)

requires a confirmation from the local user (if someone is logged on the remote console).

If nobody is logged on the remote console, the "Disconnect if at the Logon Desktop" access option (enabled by default) will not allow session establishment for a non-administrator user.

Thus, by default, a non-administrator user can not establish a remote session without approval of the locally logged-on user. If nobody is logged on, access is denied to prevent access to winlogon.

The DWRCS.INI (under %systemroot%\System32) file contains all options related to the DMRC service, including three options related to access control for non-administrators users:

- Permission Required for non Admin = yes

- Permission Required for non Admin Disconnect If At Logon Desktop = yes

- Permission Required for non Admin Force View Only = no

It is recommended to allow only administrators to connect by setting the "Allow Only Administrators To Connect" access option (NOT enabled by default).

Another interesting option for security is the "Only allow connection when at Logon Desktop" access option. When enabled, it is only possible to establish a remote session if either the system console is locked or nobody is logged on.

DMRC supports application-level IP filtering, to restrict hosts allowed to connect If possible, it is recommended to use this feature and restrict allowed IP addresses to management hosts only.

Finally, the DWMRCS service supports logging in Windows's Application eventlog (source DWMRCS, with event identifiers around 100).

Several vulnerabilities have affected DMRC in the past ( ), including a pre-authentication buffer overflow published in december 2003. Just like any software, it is thus important to maintain DMRC up to date.

4. -[ Remote administration with CLI-oriented tools ]-

CLI (Command Line) remote administration tools are sometimes needed, for instance to execute non-interactively system administration scripts.

The PsExec utility, part of Sysinternal's PsTools ( ) is a tool frequently used to execute processes remotely.

4.1 PsExec

PsExec is a convenient tool for Windows systems administrators because it allows to execute processes on a remote system, provided the server service is available (TCP ports 445 or 139) and that you have local administrator credentials on the remote system.

PsExec supports several options, described in the following webpage:

PsExec first copies its executable (psexesvc.exe, contained in the psexec.exe binary) using SMB (under %systemroot%\System32\), installs the service and starts it. These steps require administrator credentials.

If you're logged on with local credentials that also correspond to local administrator credentials (i.e., with a domain administrator account or with an account with username and password identical to a local administrator account on the remote system), additional credentials are not needed.

However, if alternate credentials are needed, it is necessary to establish a SMB session with "net use":

C:\>net use \\remote_server\IPC$ /u:administrator *

Then, the exact remote server name (such as \\remote_server) must be passed as first parameter to psexec.exe.

Warning: PsExec supports two options (-u and -p), used to specify a username and password. When used, the specified username and password are transmitted in CLEARTEXT over the network. These options are NOT needed in most cases (only if you need to overcome the limit of impersonation related to access to network resources). Instead, manually establish a session with "net use" with alternate credentials before using PsExec.

When started, the PsExeSvc opens a named pipe named \pipe\psexecsvc. This named pipe is used by the psexec.exe client to communicate with the PsExeSvc service, using an SMB session to the IPC$ share.

When a program is run, three named pipes instances are created, for stdin, stdout and stderr of the remote process. For more details, see .

The output of the "net files" command on a remote server running PsExeSvc shows the 4 named pipes (the main psexecsvc named pipe and the three named pipes used to run the remote process)

C:\>net files

ID Path User name # Locks


4089 \PIPE\psexecsvc ADMINISTRATOR 0

4090 \PIPE\psexecsvc-SERVEUR-2164-stdin ADMINISTRATOR 0

4091 \PIPE\psexecsvc-SERVEUR-2164-stdout ADMINISTRATOR 0

4092 \PIPE\psexecsvc-SERVEUR-2164-stderr ADMINISTRATOR 0

The command completed successfully.

The "net session" output shows that local administrator credentials were used to run PsExec:

C:\>net session

Computer User name Client Type Opens Idle time


\\ ADMINISTRATOR Windows Server 20 4 00:00:00

The command completed successfully.

By default, the remote process runs with the credentials specified to psexec.exe (local administrator credentials). Because the PsExeSvc service is running under the LOCALSYSTEM logon session, it is possible, if needed, to use the -s option to run the process as LOCALSYSTEM.

To summarize, with PsExec, it is possible to execute remote process on a system, provided you have local administrator credentials and access to either TCP ports 445 or 139.

4.2 Rcmd (Remote Command service)

Rcmd is an Windows NT 4.0 Resource Kit tool composed of a Windows service and a command-line client that supports remote process execution.

The Rcmd service opens a named pipe, \pipe\rcmdsvc. The Rcmd client establishes an SMB session to the IPC$ share, authenticated with an account that needs to have the InteractiveLogonRight logon right ("Allow log on locally").

If Rcmd is installed on a server, it is important to realize that any user with the "Allow log on locally" logon right can remotely execute processes on theserver, under its own identity (impersonation mechanism).

5. -[ Windows remote administration tools summary ]-

Remote administration tools using SMB (139/tcp, 445/tcp):

- Windows administration tools relying on legacy Win32 management APIs

- third-party administration tools relying on legacy Win32 management APIs


- PsExec

- Rcmd

- Dameware Mini Remote Control (at installation only)

WMI-based administration tools (135/tcp, dynamic TCP port(s))

- wmic.exe

- wbemtest.exe

- winmsd.exe

- wmimgmt.msc

GUI administration tools (dedicated ports)

- Terminal Services (3389/tcp)

- pcAnywhere (5631/tcp)

- VNC (5900/tcp)

- Dameware Mini Remote Control (6129/tcp)

6. -[ Conclusion ]-

While choosing a Windows remote administration tool, the following characteristics have to be considered:

- TCP ports required to use the remote administration feature

- supported authentication mechanisms (system authentication implemented by Windows, application-level authentication only, ...)

It is particularly important to realize that with a tool such as PsExec, one TCP port (445 or 139) is enough to administer remote Windows systems, provided you have local administrator credentials.

$Id: win_remote_admin_tools.tip,v 1.7 2005/06/15 14:56:15 marchand Exp $

Windows 2008 R2 freezes under VMWare

Windows Server 2008 R2 running as a virtual machine on a VMWare ESX can sometimes strangely freeze. This can happen when browsing folders or when browsing the event viewer. However, the machine is not really frozen, because you can still ping it and get replies. It is also possible to establish a Remote Desktop connection, but it hangs endlessly at logging in, never showing the desktop.
This issue seems to be related to a bug with the VMware tools SVGA driver:
It all boils down to the fact that you should run 2008 R2 or Windows 7 on ESX 4, Update 1, nothing earlier than that.
If you cannot update to ESX 4.0 Update 1, deselect the driver included with ESX 4.0.
  • When you install VMware Tools, select Custom or Modify in the VMware Tools installation wizard
  • Deselect the SVGA (XPDM) driver.
Otherwise you can also

Wednesday, July 21, 2010

Windows Eventlog error 5: Access denied

To solve a general access denied error in Windows 2008 R2, restore the default permissions on %SystemRoot%\System32\winevt\logs.

This is the list of rights to apply:

  • Authenticated user - List folder/read data, Read attributes, Read Extended attributes, Read permissions
  • Administrators - Full control
  • SYSTEM - Full control
  • NT SERVICE\EventLog - Full control

DFS-R limits in Windows 2003/2008 R2

Microsoft states that Windows Server 2003 R2 DFSR has the following replication limits:

  • Each member server can be a member of up to 256 replication groups.
  • Each replication group can contain up to 256 replicated folders.
  • Each server can have up to 256 connections
  • On each server, the number of replication groups multiplied by the number of replicated folders multiplied by the number of simultaneously active connections must be kept to 1024 or fewer.
  • A replication group can contain up to 256 members.
  • A volume can contain up to 8 million replicated files, and a server can contain up to 1 terabyte of replicated files.
  • The maximum tested file size is 64 gigabytes.

On the other side, in Windows Server 2008 R2 and Windows Server 2008, there is no longer a limit to the number of replication groups, replicated folders, connections, or replication group members.

Whatever Microsoft says, remember that there is not a hard limit on the number of files that can be replicated. DFS Replication maintains an internal database per volume for all metadata information. And, theoretically, the Jet database can grow to as large as 32 TB.

What’s more, DFS Replication has no restrictions on the size of files replicated. As long as the staging space is appropriately and DFS Replication does not hit any space issues, it can replicate any size of files.

So, it shoud be possible to exceed these limits and still get acceptable replication performance.

Monday, July 19, 2010

DFSR diagnosis

The Distributed File System Replication (DFSR) service is a new multi-master replication engine that is used to keep folders synchronized on multiple servers.

To test replication over a DFSR link, use the following commands on any node:

  • dfsrdiag backlog /RGname:dfsr_replica /rfname:data_to_replicate /sendingmember:server01 /receivingmember:server02 /verbose
  • dfsrdiag backlog /RGname:dfsr_replica /rfname:data_to_replicate /sendingmember:server02 /receivingmember:server01 /verbose

To test replication speed, use the following commands from any node:

  • dfsrdiag propagationtest /RGname:dfsr_replica /rfname:data_to_replicate /testfile:canarytest2
  • Wait a few minutes (between five and ten) !!
  • dfsrdiag propagationreport /RGname:dfsr_replica /rfname:data_to_replicate /testfile:canarytest2 /reportfile:c:\canaryproprep.xml
  • Open c:\canaryproprep.xml and retrieve <CreateTime> and <UpdateTime> for every DFSR member and convert them to human readable values with W32TM
  • W32tm /ntte 129030080938493490 => 149340 08:54:53.8493490 - 18/11/2009 09:54:53 (local time)
  • W32tm /ntte 129030084955331240 => 149340 09:01:35.5331240 - 18/11/2009 10:01:35 (local time)
  • W32tm /ntte 129030084955076620 =>149340 09:01:35.5076620 - 18/11/2009 10:01:35 (local time)
The difference between these values will give you the time in minutes for replication to occur (in this example the answer is 6)

FAILED: agent.internal.fault.PlatformError.summary

When virtualising a physical server, you could encounter a “FAILED: agent.internal.fault.PlatformError.summary” error in VMWARE Converter.

To solve this problem, start by exporting the logs to a zip file, open it and navigate to “Documents and Settings/All Users/Application Data/VMware/VMware vCenter Converter Standalone/logs”

Analyse the last logfile for error. You will find that Converter generated a log file: Storing at "C:\WINDOWS\Temp\vmware-temp\vmware-SYSTEM\agent-task-***.zip"

The problem is probably in the firewalls between the physical system to be converted and the ESXi server... with the needed ports opened everything should works just fine.

Otherwise, if your ESX and the physical server to P2V are on different VLANs, add a temporary Service Console to allow them to communicate. The ESX needs in fact to communicate with the VMWARE agent installed on the physical server.

This should allow proper network traffic between ESX and the server to virtualise.

It could also be a DNS issue, so make certain you can nslookup the source server from the destination server.

Friday, July 16, 2010


If you need to RDP a remote Windows server and all the sessions seem to be unavailable, you may use two utilities to kill offending/exceeding sessions: qwinsta and rwinsta

Here’s the procedure:

  • Type “Psexec \\servername –u username –p password –c cmd”
  • Type “qwinsta”
  • Choose a session to kill and note its id
  • Type “rwinsta id”

... because the real sysadm can do it via the command line!

Additional notes:

QWINSTA.EXE: queries the sessions

qwinsta /?

Display information about Terminal Sessions.

QUERY SESSION [sessionname | username | sessionid]

[/SERVER:servername] [/MODE] [/FLOW] [/CONNECT] [/COUNTER]

sessionname Identifies the session named sessionname.

username Identifies the session with user username.

sessionid Identifies the session with ID sessionid.

/SERVER:servername The server to be queried (default is current).

/MODE Display current line settings.

/FLOW Display current flow control settings.

/CONNECT Display current connect settings.

/COUNTER Display current Terminal Services counters information.

RWINSTA.EXE: removes the sessions

rwinsta /?

C:\Documents and Settings\stever>rwinsta /?

Reset the session subsytem hardware and software to known initial values.

RESET SESSION {sessionname | sessionid} [/SERVER:servername] [/V]

sessionname Identifies the session with name sessionname.

sessionid Identifies the session with ID sessionid.

/SERVER:servername The server containing the session (default is current).

/V Display additional information.

The session is not authenticated in VMware

When trying to P2V a physical server, you might get the following error message within your VMware vCenter Converter Standalone:

“The session is not authenticated”

To fix this problem, go into your task manager and kill all the pending VMware converter processes that are currently running.


If this should not work, other solutions can be applied:

  • Verify that servers are synchronized
  • Restart the VMware Converter service
  • Restart the Virtual Center Server
In any case, what is important to remember is that there must be just one instance of converter in execution on both Virtual Center server and physical server to P2V...

W e l c o m e

Welcome to the happy SYSADM website!!!
Related Posts Plugin for WordPress, Blogger...