Showing posts with label command line. Show all posts
Showing posts with label command line. Show all posts

Monday, August 27, 2007

Things that makes your life easier

PowerShell Community Extensions has a powerful utility called echoargs.exe. This file can help you "see" how the target file/function processes the arguments sent to it, thus troubleshooting any argument related errors.

One such case discussed in the PowerShell Newsgroup, where Keith explained what was the problem (You can find a copy of the post here).

I couldn't resist, so I fired PowerShell :)


function echo-args{
    for($i=0;$i -lt $args.length;$i++){
        "Arg $i is <" +$args[$i]+">";
    }
}

>> echo-args -n -betfsboot.com iso WinPE2.iso

Arg 0 is <-n>
Arg 1 is <-betfsboot>
Arg 2 is <.com>
Arg 3 is <iso>
Arg 4 is <WinPE2.iso>

 

Enjoy!

Sunday, August 26, 2007

Exchange 2007 Transition - First impressions


Today I finished installing Exchange 2007 to coexist with Exchange 2003. The installation process went fine except for two issues regarding connectors. 

The environment contains one Exchange 2003 (which is also a DC/GC, BAD THING TO DO, Inherited). Here are the steps taken: 

  1. Make sure the Domain functional level is Windows server 2003.
  2. Switch the legacy Exchange organization (2003) to Native mode.
  3. Suppressing link state updates - via registry.
  4. Extending Active directory scheme. I could install Ex2007 and let setup make all necessary changes, but preferred to do the process manually. this includes:
    • Run setup.exe /PrepareLegacyExchangePermissions.
    • Run setup.exe /PrepareScheme.
    • Run setup.exe /PrepareAD.
    • Run setup.exe /PrepareDomain.
  5. Installing Exchange 2007 with the following Roles in command-line mode:

    Note: During setup accept the Routing connector creation dialog. There is also the option to install Exchange from command line:
    >> Setup /mode:Install /roles:HT,CA,MB,MT /EnableLegacyOutlook /on:<OrgName>
    • Hub Transport role (HT).
    • Client Access Role (CA).
    • Mailbox Role (MB).
    • Management tools (MT).
    • /EnableLegacyOutlook. Creates a Public Folder database on the Exchange 2007 server for sharing of Free/Busy calendar information using the legacy Outlook client.
  6. Moved all database stores to another physical disk.
  7. Replicating public folders to Exchange 2007.
  8. Installing latest Exchange Rollup (v4).

 

When setup finished I moved one mailbox to the 2007 server and tested it with Outlook 2003. All looked fine but no mail could be send or received even though nothing was on the Outbox folder. All messages were stuck in the Queue.

Checked the Application log and found:

 

Event Type:    Warning
Event Source:    MSExchangeTransport
Event Category:    Routing
Event ID:    5006
Date:        8/26/2007
Time:        16:13:52
User:        N/A
Computer:    ServerName
Description:
Cannot find route to Mailbox Server CN=SERVER,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domainName,DC=com for store CN=UsersStore,CN=First Storage Group,CN=InformationStore,CN=ServerName,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domainName,DC=com in routing tables with timestamp 26/08/2007 13:13:52.  Recipients will not be routed to this store.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 
I suspected that the creation of the Routing connector during setup (Phase 5 note) didn't succeeded. I launched PowerShell and searched for cmdlets that contain the word "Routing" in its name.

PS C:\Scripts> get-command *routing*

CommandType     Name
-----------     ----
Cmdlet          Get-RoutingGroupConnector
Cmdlet          New-RoutingGroupConnector
Cmdlet          Remove-RoutingGroupConnector
Cmdlet          Set-RoutingGroupConnector

 

I Executed Get-RoutingGroupConnector and nothing returned. 
Then I executed New-RoutingGroupConnector and mail started flowing internally.

>> New-RoutingGroupConnector -Name "InternalRGC"
-SourceTransportServers "Ex07SRV"
-TargetTransportServers "Ex03SRV" 
-Bidirectional $true

To redirect inbound mail from the Internet to the 2007 server I changed the "Permission Group" settings on the Default server receive connector (under Server Configuration node > Hub Transport ) to allow Anonymous users to connect via SMTP and thus internal users to receive emails from outside the organization. Then I issued the following:

>> New-SendConnector -Name "Internet Mail Connector" -AddressSpaces "*"

 

OOOOfffffff <sigh>, "Out of the box" I expected setup to create the Routing group for internal and external use, and that mail flow will behave transparently, but hey... Now I have 381 more cmdlets to work with, CANT WAIT!.

 

Shay

Sunday, January 21, 2007

Real time command line spy

Generally, every script you write involves running some Windows built-in tools. Applications like regedit.exe or cmd.exe are the most common. For this tools to operate within a script, a command line argument must be supplied to tell the application what "task" to perform otherwise it will just run with the default settings.

As I see it, command line arguments and switches are both fascinating and powerful. There are even undocumented switches, which makes them even more mysterious. For example, running control panel applets can be done with tools like control.exe or rundll32.exe, both with some arguments.

CONTROL.EXE <cplfilename.cpl> RUNDLL32.EXE <dllname>,<entrypoint> <optional arguments>

To run the Internet Properties dialog, type:

control.exe inetcpl.cpl or rundll32.exe shell32.dll,Control_RunDLL INETCPL.CPL

You can even open the applets with another tab in front (using the tab Index number). To open the Internet Properties dialog with the Privacy tab in front, type:

control.exe inetcpl.cpl,,2 rundll32.exe shell32.dll,Control_RunDLL INETCPL.CPL,,2

Traditionally, you will use the /? switch to reveal your application's help, but, if you run rundll32.exe /? you'll end up with nothing, searching for help on these kind of files can be a quiet a challenge, and as you can see with the rundll sample this is not ordinary stuff like cmd.

For quite some time I was puzzled by this. How can I find the rundll's or any other file command line switches and arguments? Can I find more than "exist" in the default documentation or help parameter?.

I started to Google, with no luck. Including the words "command line" in Google's search was a pain. I had to filter out dozens of links, ohhh... until I came across Bryan Keadle's Cool Tools page.

One of Bryan tools called "Intercept" was made exactly for this task. Intercept will replace itself with the selected program, show the parameters being passed, then continue on to the original executable. Fantastic, I downloaded the file, tested it and it worked just fine.

While "Intercept" did a great job on a small scale I was looking for a better solution. Than I came across SysInternals "Process Explorer" (now hosted on TechNet). If you used Sysinternals tools before, than names like regmon, filemon, tcpview and others are no stranger to you (if you didn't use there tools shame on ya :-), you can download the entire Sysinternals Suite (8 MB) from here).

Double-clicking any process in Process Explorer launched the process property dialog. This dialog lists a plethora of information on the process including the command line that started it.

 

Now, all I had to do is click the processes and investigating their command line, and testing them offline. As for the above rundll example, go to the control panel and run any applet you like, once you launched it look for rundll process in Process Explorer, double-click it and view its command line, then you can include it in your scripts.

As for processes that took very small amount of time to execute and appear in the display, I used the "spacebar" key to "freeze" the display from refreshing and then double-clicked the process. This method became very wearying while waiting for processes to execute, much like a mouse and cat chase. The last step in this quest was the release of SysInternals Process Monitor (By Mark Russinovich and Bryce Cogswell).

Process Monitor includes regmon, filemon and Process Explorer in one tool. It captures all the activity of registry, file system, and processes/threads in real time, and logs the results to a file on the local disk. Boom, this was what I looked for. Here is my way of real time spying/monitoring command lines:

1. Run procmon.exe
2. Toggle off registry activity
3. Right Click any Column header and choose "Select Columns..." (or Click Options > Select Columns) and uncheck everything except "Process Name" and "Command Line".

 

4. Viola! Procmon.exe scrolls the results and from now on, no command line switch is immune.

 

In addition filters can be applied to adjust the displayed processes. If you wish to exclude a Process, just right click it and choose "Exclude > Process Name".

Finally, you can save the results to a CSV file for later use. One can even make a Command line Database :-)

 

I strongly recommend viewing Mark's session on "Advanced Windows Troubleshooting with Process Monitor"

 

Enjoy $hay