Windows 7, Windows Server 2008 R2 and Exchange Server 2010 | Microsoft

Default password for all TMNet Streamyx supported modem.

1. ZTE modem
* IP Address: 192.168.1.1
* Username: ADSL
Password: expert03
* Username: ZXDSL
Password: ZXDSL
* Username: admin
Password: telekomst
2. KASDA modem:
* IP Address: 192.168.1.1
* Username: admin
Password: telekomst
3. ArtNet modem:
* IP Address: 192.168.1.1
* Username: admin
Password: telekomst
* Username: admin
Password: admin
* Username: admin
Password: password
4. Triz modem:
* IP Address: 192.168.1.1
* Username: admin
Password: aaaaaaaa
5. Aztech modem:
* IP Address: 10.0.0.2 OR 192.168.1.1
* Username: admin
Password: blank
* Username: admin
Password: password
* Username: admin
Password: admin
6. Billion modem:
* IP Address: 192.168.1.254
* Username: admin
Password: password
7. Huawei modem:
* IP Address: 192.168.1.1
* Username: admin
Password: admin
8. Hyundai HSE-220 Modem:
* IP Address: 192.168.1.1
* Username: ADSL
Password: ADSL
* Username: admin
Password: ADSL
* Username: root
Password: root
9. Riger DB102:
* IP Address: 192.168.1.1
* Username: tmadmin
Password: tmadmin
10. TP-LINK MODEM / ADSL2 / ROUTER:
* IP Address: 192.168.1.1
* Username: admin
Password: admin

Create a shared variable for passing data from subreport to main report

Since CR not allowed to sum (formula), e,g, sum({@mainformula), I
calcualte the grand total from subreport. detailed steps are:

1. In subreport, create formula called subformula, the shared valiable = grand total

WhilePrintingRecords;
Shared CurrencyVar myTotal :=Sum ({Command.SUM(AB.FEEAMOUNT)})

2. In main report, created a formula called mainformula

WhilePrintingRecords;
Shared CurrencyVar myTotal;
myTotal

3. Then put this mainformula on the main report underneath of subreport. Here what you want for the result.

Removable USB/thumb drives use the Autorun feature to load files when the drives are plugged into the USB port. Malware exploits the Autorun feature to spread from thumb drive to PC. Disable the autorun feature to prevent malware from spreading.
Difficulty: Easy
Time Required: 2 minutes
Here's How:

1. The easiest and most effective means to truly disable autorun can be done via this simple autorun registry hack:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"
2.

To use this method, Open Notepad and copy/paste the following into a text file:

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

Save the file as something.reg. (You have to be sure to change the "Save File as Type" to "All Files" before saving, or Windows will try to save it as a .txt even if you typed in .reg.
3.

Locate the file you just saved and double-click the file to run it. You will receive a prompt asking if you want to add the data to the registry. Click yes to allow the modification.
4.

The above method nulls any request for autorun.inf and works on XP Home or Pro, as well as Windows Vista. Credit for this tip goes to Nick Brown.

If you opt to disable autorun using any other method, you will first need to install an autorun patch from Microsoft that allegedly resolves issues that cause autorun to run even after it's been disabled (using methods other than the above recommended method).
5. XP Pro users who have installed the appropriate Microsoft patch for your system and wish to disable autorun using a method other than described above, follow steps 3 through 8 only. XP Home users begin at step 9. Vista users, see How to Disable Autorun in Windows Vista.
6. Windows XP Pro users: Click Start and then click Run. Type gpedit.msc and click OK. The Group Policy window will open. In the left pane, double-click Administrative Templates
7. In the right pane, double-click System, scroll down the list and double-click Turn Off Autoplay
8. In the Turn Off Autoplay Properties window, select Enabled. From the dropdown next to Turn Off Autoplay on, select All drives and then click OK. Exit Group Policy by selecting File, then choosing Exit from the menu.
9. XP Home users will need to make the changes by editing the registry directly. To begin, click Start and then click Run
10. Type regedit and click OK. The Registry Editor window will open.
11. In the left pane, navigate to:
HKEY_CURRENT_USER
Software
Microsoft
Windows
CurrentVersion
Policies
Explorer.
(Note: For help navigating the registry, see the Windows Basics System Registry tutorial).
12. With Explorer highlighted, in the right-pane right click the value NoDriveTypeAutoRun and select Modify from the drop down menu. The base value will be set to Hexadecimal. If not, select Hexadecimal.
13. Type 95 and click OK.
Note that this will stop Autorun on removable/USB drives, but still allow it on CD ROM drives. If you want to disable autorun on both, substitute b5 for the 95. (Thanks to Ian L. of Manitoba for the tip).
14. Exit Registry Editor by selecting File, then choosing Exit from the menu.
15. You will now need to reboot your computer for the changes to take effect.

When you having this kind of error message prompt out when you are using ado components. Means this is cause by the field lenght was not compatible, please check you form input lenght and the database table field lenght. Please make sure it is same.

You may have faced the issue of losing the SQL Server SA password. Perhaps you followed the security best-practice of removing the builtin\Administrators from the sysadmin server role, and no one you can find is in the sysadmin role. At this point you may think that your only options are to reinstall SQL Server and attach the databases, or to directly access the master database files, which may potentially damage the data.

SQL Server 2005 provides a better disaster recovery option for this scenario that is non-intrusive for master DB and that will help you preserve any objects and data stored in master DB (such as logins, certificates, Service Master Key, etc.) intact. Members of the Windows Administrators group now have access to SQL Server when SQL Server is in started in single-user mode, also known as “maintenance mode “.

Using the single-user mode, SQL Server 2005 prevents a Windows Administrator to abuse this privilege to act on behalf of the sysadmin without being noticed. This allows Windows Administrator accounts to perform certain maintenance tasks, such as installing patches.

In order to start SQL Server in single-user mode, you can add the parameter “-m” at the command line. You can also use the SQL Server Configuration Manager tool, which provides proper controls for the file access and other privileges. To use the Configuration Manager tool to recover your system, use the following steps:

1. Open the Configuration Manager tool from the "SQL Server 2005| Configuration" menu
2. Stop the SQL Server Instance you need to recover
3. Navigate to the “Advanced” tab, and in the Properties text box add “;–m” to the end of the list in the “Startup parameters” option
4. Click the “OK” button and restart the SQL Server Instance

NOTE: make sure there is no space between “;” and “-m”, the registry parameter parser is sensitive to such typos. You should see an entry in the SQL Server ERRORLOG file that says “SQL Server started in single-user mode.”

5. After the SQL Server Instance starts in single-user mode, the Windows Administrator account is able to connect to SQL Server using the sqlcmd utility using Windows authentication. You can use Transact-SQL commands such as "sp_addsrvrolemember" to add an existing login (or a newly created one) to the sysadmin server role.

The following example adds the account "Buck" in the "CONTOSO" domain to the SQL Server "sysadmin" role:

EXEC sp_addsrvrolemember 'CONTOSO\Buck', 'sysadmin';

GO

6. Once the sysadmin access has been recovered, remove the “;-m” from the startup parameters using the Configuration Manager and restart the SQL Server Instance

Important Security Notes:

This process should only be used for disaster recovery when no other method to access the system with a privileged (i.e. sysadmin or equivalent) is available.

This process allows a Windows Administrator account to override their privileges within SQL Server. It requires explicit and intrusive actions that can be monitored and detected, including:

· Stop SQL Server and restart it in single use mode

· Connecting to SQL Server using Windows credentials


Special thanks to Buck Woody (http://blogs.msdn.com/buckwoody/) for his help in writing this article.

The VersionInfo library basically just wraps the Win32 GetFileVersionInfo (and related) API functions. The library makes it very easy to read values from the Version Info resource of Windows executables and DLLs.
Features

* Reads all integer version info values:
File version, product version, File flags, OS, file type, file sub-type and file date.
* Reads any named version info string value such as:
Product Name, Product Version, Company, Copyright, etc.
* Supports languages, character sets and translations.
* Optionally extends the TApplication class with a version info property.

The TApplicationVersion class

The TApplicationVersion class contains the core functionality of the library. The following is the public interface of the class:

TApplicationVersion = class
public
constructor Create(const Filename: string);
destructor Destroy; override;
class function VersionToString(Version: int64): string;
class function StringToVersion(const Value: string): int64;
function GetString(const Key: string; LanguageID: integer; CharsetID: integer): string; overload;
function GetString(const Key, TranslationID: string): string; overload;
function GetString(const Key: string; Index: integer = 0): string; overload;
property Valid: boolean;
property Strings[const Key: string]: string; default;
property FileVersion: int64;
property ProductVersion: int64;
property FileFlags: DWORD;
property OS: DWORD;
property FileType: DWORD;
property FileSubType: DWORD;
property FileDate: int64;
property LanguageID[Index: integer]: WORD;
property CharsetID[Index: integer]: WORD;
property LanguageNames[Index: integer]: string;
property TranslationCount: integer;
end;

The TApplicationVersionHelper class

As a bonus there’s also a class helper that extends TApplication with a version info property:

TApplicationVersionHelper = class helper for TApplication
public
property Version: TApplicationVersion;
end;

To enable the class helper you just include the ApplicationVersionHelper unit in your uses clause.
Examples
Example 1

Read the version number from a file and display it in a message box

uses
VersionInfo;
...
const
Filename = 'foobar.exe';
var
FVersionInfo: TVersionInfo;
Version: string;
begin
FVersionInfo := TVersionInfo.Create(Filename);
try
Version := TVersionInfo.VersionToString(FVersionInfo.FileVersion);
finally
FVersionInfo.Free;
end;
ShowMessage(Format('The file %s has version %s', [Filename, Version]));
end;

Example 2

Set the application title to the description value specified in the version resource

uses
Forms,
VersionInfo,
ApplicationVersionHelper; // Enable the class helper
...
begin
Application.Title := Application.Version['FileDescription'];
end;

-------------------------------------------------------------------------------------

Source Code Sample --> Download

Symptoms

1. Windows Firewall/Internet Connection Sharing (ICS) service not listed in Services.msc Console.
2. Windows Firewall/Internet Connection Sharing (ICS) service is listed in Services Console, but you may not be able to start the service.
3. The following error occurs when accessing the firewall settings (firewall.cpl)

Due to an unidentified problem, Windows cannot display Windows Firewall settings.

Cause

Case 1: This happens due to missing or corrupt SharedAccess registry key, which represents the Windows Firewall Service. This usually occurs if your system is infested with Virus or other Malware, or in the aftermath of Virus removal. In conjunction with the solution provided in the article, it's advisable to run a thorough cleanup of the system.

Case 2: You have Windows Live OneCare installed. Windows Live OneCare has its own Firewall which monitors both inbound and outbound connections. Because two firewalls should not be turned on at the same time, Windows Live OneCare turns off Windows Firewall if the latter is running. [More info]. Therefore, Windows Live OneCare users can safely ignore the error message concerning Windows Firewall.
Resolution

Solution for Case 1:

Download sharedaccess.reg (only for Windows XP systems with Service Pack 2 or Service Pack 3 applied) and save to Desktop. Then double-click the file to merge the contents to the registry. The Services entry will be created. Restart Windows (mandatory step, otherwise the following NETSH command might display an error).

After restarting Windows, execute the following command via Start, Run dialog:

CMD /K NETSH FIREWALL RESET

Launch firewall applet from Control Panel, and see if you're able to configure the Windows Firewall settings.

If the above steps do not help, as a last resort solution (before attempting to reinstall the Service Pack), give the following commands a try:

Click Start, Run and type:

rundll32 setupapi,InstallHinfSection Ndi-Steelhead 132 %windir%\inf\netrass.inf

The above command repaired most of the Windows Firewall settings when I tested. After running the above command, restart Windows and then run the following:

CMD /K NETSH FIREWALL RESET

Attempt to start Firewall applet. Start the Windows Firewall service when prompted.

Before we even talk about Delphi programming, we'll get accustomed to Regedit, which is a tool that windows provides for searching and modifying the registry. Start up regedit either by going Start -> Run -> regedit, or going to your system32 folder and double clicking regedit.exe.

Each program installed on the computer leaves a little bit of information behind in order for it to properly load to your specifications. (Cheat Engine leaves behind quite a lot of registry keys, just btw) This is mainly stored in the Registry, which is what we're looking at in regedit. Much of the information on programs will be stored in the HKEY_LOCAL_MACHINE\SOFTWARE path. However, some will be stored in the HKEY_CURRENT_USER\SOFTWARE path (this includes Cheat Engine registry entries).

Each Registry key contains a little bit of information in the form of Strings (SZ), DWORD, and Binary. Strings, of course, store arrays of characters. DWORD is mainly used for Hexidecimal entries, but it can also be used for Decimal (base Ten) entries. Binary is used to store arrays of bytes, and that's all that matters for this tutorial.

Regedit works just like Windows Explorer, in list Details view. It shows the each Key's name, data type, and value. You can double click to change a value, but that is not recommended.

I was working with the registry in an attempt to be able to access the proper installation folder of windows no matter what platform I was on. Finding the windows file path will be the first example in this little tutorial. First, though, you need to know some delphi registry commands.

Working with the Registry in Delphi
As with any other addon to Delphi code, you'll need add something to your uses list. For this, just add registry to the list, like so:

Quote:
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, Registry;
Now, as with any windows application, you'll need to click a button or something to start your procedure(s), so let's add a button to your main form.

Now, double click that button, and we can get to working with the Registry.

In order to use Registry keys, we'll need to declare a variable with variable type TRegistry. So in your procedure, add a var section and put something like this:

Quote:
Procedure TForm1.Button1Click(Sender: TObject);
var
Reg: TRegistry;
begin

end;
In order to implement a registry key, you need to .create it so let's put:
Reg := TRegistry.Create; right after the begin.

Be sure to put a Reg.Free; after you finish... (Create and Free go hand in hand...)

Then you need to assign a root path, or it assumes it to be HKEY_CURRENT_USER (which is not as good as HKEY_LOCAL_MACHINE). So we put: Reg.Rootkey:= HKEY_LOCAL_MACHINE;

For now, i'll just list out the commands that we'll use in this tutorial:
Bold = required; Italics = not required

TRegistry:
procedure OpenKey- Moves the focus onto the registry path specified.

Syntax: TRegistry.Openkey(path: string, CreateIfNotExistant: BOOLEAN);

The path is added onto the rootkey to form the whole path such as HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows where the blue is the rootkey, and the red is the path.

The CreateIfNotExistant boolean variable indicates whether or not to create the registry path if it does not exist. Typically, this would be FALSE.

function ReadString- Reads a string from the key specified. Returns the string;

Syntax: some variable (string) := ReadString(keyname: string,MaxNumOfChar: Integer);

Keyname is the name of the key to be read from.
MaxNumOfChar is the user-specified maximum number of characters to be read

These two functions are enough for this tutorial. If you want to fool around with the registry more, you'll want to refer to Delphi help.
Finding the Windows Installation Path:
For this part, you won't need regedit, as I will provide you the path to windows. We'll start off with a skeleton of the program:

Quote:
Procedure TForm1.Button1Click(Sender: TObject);
var
Reg: TRegistry;
WindowsFilePath: String;
begin
Reg:= TRegistry.Create;
Reg.Rootkey:= HKEY_LOCAL_MACHINE;
// Code goes here
Reg.Free;
end;
Now, we'll observe that windows' registry key is in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion. So let's openkey that.

Quote:
Procedure TForm1.Button1Click(Sender: TObject);
var
Reg: TRegistry;
WindowsFilePath: String;
begin
Reg:= TRegistry.Create;
Reg.Rootkey:= HKEY_LOCAL_MACHINE;
Reg.Openkey('\SOFTWARE\Microsoft\Windows NT\CurrentVersion', FALSE);
// Code goes here
Reg.Free;
end;
This path exists, so the FALSE shouldn't matter.

Now, we'll notice that the key name is 'SystemRoot', so we'll read string from that key, and voila, we have the windows installation folder.

Quote:
Procedure TForm1.Button1Click(Sender: TObject);
var
Reg: TRegistry;
WindowsFilePath: String;
begin
Reg:= TRegistry.Create;
Reg.Rootkey:= HKEY_LOCAL_MACHINE;
Reg.Openkey('\SOFTWARE\Microsoft\Windows NT\CurrentVersion', FALSE);
WindowsFilePath:= Reg.ReadString('SystemRoot');
Reg.Free;
end;
Ok, this does BASICALLY nothing right now, so we'll just have a little fun in the windows folder, shall we?

Nah, i'm just joking. We'll just open regedit, not matter what system we're on.

Quote:
Procedure TForm1.Button1Click(Sender: TObject);
var
Reg: TRegistry;
WindowsFilePath: String;
begin
Reg:= TRegistry.Create;
Reg.Rootkey:= HKEY_LOCAL_MACHINE;
Reg.Openkey('\SOFTWARE\Microsoft\Windows NT\CurrentVersion', FALSE);
WindowsFilePath:= Reg.ReadString('SystemRoot');
Reg.Free;
ShellExecute(handle,'',PChar(Concat(WindowsFilePat h,'\system32\regedit.exe')),'','',SW_SHOW);
//If you didn't know what that meant, don't worry about it
end;
Be sure to add shellapi to your uses list if you're going to use ShellExecute.

Getting Application's File Path from Registry
This step is a little harder, because different companies put different names on their registry keys, and they put them in a lot of different places. I'm assuming we're all using Borland Delphi 7, so we'll just use that as an example.

First, let's load up regedit and try to find a path to Borland.

First, we look in Local Machine, and voila, we find it under \software\Borland.

Now we'll find Delphi's keys.

We look in Borland, and we find Delphi, however there are no keys in that folder. However, when we look under 7.0, we find a key called 'RootDir'. Even the name gives it away, so let's keep that key.

We've arrived at...

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Borland\Delphi\7.0
Keyname: RootDir

So let's make a program that looks for the Root Directory.

Quote:
Procedure TForm1.Button1Click(Sender: TObject);
var
Reg: TRegistry;
DelphiPath: String;
begin
Reg:= TRegistry.Create;
Reg.Rootkey:= HKEY_LOCAL_MACHINE;
Reg.Openkey('\SOFTWARE\Borland\Delphi\7.0', FALSE);
DelphiPath:= Reg.ReadString('RootDir');
Reg.Free;
end;
That was simple enough, however we saw that the Keyname changed, so we have to be cautious.

Whenever you're looking for a directory key, look for giveaway names like 'RootDir' or 'InstDir' or something like that.

Now, to implement this into a button that loads the program, we'll have to look in that path to find where the executable is.

It just so happens that the delphi executable is not in the rootdir, but in a subfolder: \Bin\delphi32.exe

So we'll put that into one giant string by using concatenation (Concat();)

DelphiPath:= Concat(DelphiPath,'\Bin\delphi32.exe');

To execute this program, we do:

shellexecute(handle,'',PChar(DelphiPath),'','',SW_ SHOW);

Read more on shellexecute in Delphi Help.

That concludes this tutorial...

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows

1. Stop the Terminal Services Session Directory service.
2. In the registry, locate the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tssdis\Parameters
3. If the Parameters key does not exist, create it.
4. Add the following DWORD value:
TraceOutputMode
5. Select the option you want:
* 0 (no output)
* 1 (output to debugger)
* 3 (output to log file)
6. Start the Terminal Services Session Directory service. If you selected option 3 in step 5, Terminal Service Session Directory places the output in a log file that is named Tssdis.log in the System32 folder.

The Terminal Services Session directory log file contains the following entries:

* Session Directory service started
* Session Directory service stopped
* Machine joins session directory
* Machine leaves session directory
* User logs in
* User disconnects
* User reconnects
* User logs out
* Session Directory-related event log messages.

Important If you stop and then restart the Terminal Services Session Directory service, you clear all Terminal Services Session Directory data. Do this only if it is not a problem to do so.

How to safely change the regional settings for IIS.

I recently installed a new server and ran in to a problem I've incurred before - despite me hanging the servers regional settings to use U.K. formatting for dates and numbers, all my ASP pages were defaulting to U.S. regional settings. This is because Microsoft, in all their wisdom, decided that IIS (Internet Information Services) should take its regional settings from the IUSR account (an account whose password is generated by the server and not known to the server administrator - go figure).

Now many ASP purists will say that you should always set the locale of your application (e.g. website) anyway, forcing the server to acknowledge your region of choice - I agree. The problem is however, that I host websites I haven't created myself and also that many third party solutions and dreamweaver extensions) physically format the date how they want it - making regional settings ineffective.

Although I've seen all sorts of solutions out there, from registry changes to resetting the IUSR password, I hadn't found one I was entirely comfortable with. Firstly, registry setting changes always make me twitchy and secondly, resetting the password to the IUSR account can cause windows to permanently deny access to some IUSR recources.
The Solution

I took the obvious route instead and decided to find out how to get hold of the IUSR password that generated automatically and simply use the RUN AS option when firing up the regional settings dialogue to run them as the IUSR - so, down to business:

In order to allow the password to appear as anything other than asterisks you need to update the adsutil.vbs script (found in the AdminScripts folder in the Inetpub folder (often

C:/InetPub/AdminAcripts). Open the adsutil.vbs file in Notepad and search for "IsSecureProperty =

True", replace it with "IsSecureProperty = False" and save the file (keep it open so you can easily change it back afterwards).

Open a command prompt window (START > RUN > Type 'cmD' > OK)Browse to the InetPub/AdminScripts folder, for example:

C: (press enter)

CD \ inetpub\AdminScripts


To Retrieve the IUSR Password, enter this command:

cscript adsutil.vbs get w3svc/anonymoususerpass

Should return something like: anonymoususerpass : (STRING) "/fre5hJe7x"!39I"

To Retrieve the IWAM Password, enter this command:

cscript adsutil.vbs get w3svc/wamuserpass

Should return something like: wamuserpass : (STRING) "1like808!"

Now in the Control Panel, hold down the shift key and right click on the "Regional Settings" icon

Select "Run As" from the menu that appears

Login as the IUSR_yourServerName using the password retrieved above

Change the regional settings to whatever you need them to be for IIS and your done.

You may need to restart the server for the changes to take effect.

Don't forget to change the adsutil.vbs line back to read "IsSecureProperty = False"!