Fix Active Directory replication issues

In Windows Server 2003, the replication process is responsible for keeping each domain controller updated with the latest Active Directory information. The replication process is also responsible for keeping DNS replicas synchronised.

As you can see, replication is a very important part of the Windows Server 2003 network operating system. So what do you do when replication fails? For that matter, how do you even know when a failure has occurred? Here are some answers to these questions and how to fix the replication process.

How does replication work?
Before you can fix the replication process, you need to understand how it works. As I mentioned earlier, replication is used to keep both domain controllers and DFS replicas synchronized. There are a few other tasks that use replication as well. For the purposes of this article, I will focus my discussion on Active Directory replication that occurs between domain controllers.

If you have ever worked with Windows NT, then you are probably familiar with the PDC and BDC domain controller roles. In such an environment, if someone needs to make an update to the Security Accounts Manager, the update gets applied to the PDC. The PDC then alerts the BDCs to the update and the BDCs download the updates and use them to update their own copies of the Security Accounts Manager. This structure is known as single master replication.

In contrast, Windows 2000 and Windows 2003 use multi-master replication. In multi-master replication, there is no PDC or BDC. Every domain controller contains a writable copy of the Active Directory database. If an administrator makes an update to the Active Directory, the update is applied to the closest available domain controller. The domain controller then uses the replication process to apply the update to the other domain controllers.

Because of the multi-master replication model, the Active Directory must have a technique for resolving conflicts. For example, suppose that two different administrators are making changes to the same attribute of the same user account at the same time. Now, suppose that those changes get written to two different domain controllers. When the next replication cycle occurs, you will have two domain controllers attempting to write contradictory data to the other domain controllers.

To get around this problem, Windows relies on a "most recent change wins" mentality. This means that Windows looks at the timestamp for both changes. Whichever of the two changes was made most recently will be the change that takes precedence. The other change will be overwritten.

I mention this because I've seen situations in which two administrators try to apply updates to user accounts and can't figure out why some of their changes are undone. If you suspect that you might have a replication problem, do a little checking to make sure that two or more people are not trying to update the same information at the same time.

Another aspect of replication that I want to touch on is something called Inter-site replication. Inter-site replication is domain controller replication across two or more sites.

The idea behind Active Directory sites is that you want to avoid congesting slow WAN links with excessive replication traffic. Imagine for a moment that you have a domain spanning two offices and that each of the two offices has ten domain controllers. Also, imagine that these two offices are separated by a slow WAN link.

In a situation like this, every time anyone makes a change to the Active Directory, the change is replicated to nineteen other domain controllers. It also means that, since there are nineteen other domain controllers that have to be updated, nineteen different copies of the same data are flowing across your network. To make matters worse, ten separate copies of the same identical data are flowing across your WAN link.

Now, imagine that someone is performing an Active Directory-intensive process, such as creating a hundred new user accounts. This process would cause at least a thousand different update sequences to flow across your WAN link. It is very possible that all of this traffic could choke out the link, preventing other, more important, traffic from flowing across it.

The solution to this problem is to divide the domain into two sites. In a situation like this, one domain controller in each environment is designated as a bridgehead server. The bridgehead server is responsible for sending and receiving batches of Active Directory updates. To see how sites work, let's return to my example of the company with ten domain controllers in each office, separated by a WAN link.

In this situation, if someone in an office made an update to a domain controller, only nine updates would be sent out instead of nineteen. These updates are designed to update the domain controllers in the local site. Remember, however, that one of these domain controllers is acting as the bridgehead server for the site. The bridgehead server receives the updates and then sends a single copy of the update across the WAN link to the remoter bridgehead server. The remote bridgehead server receives the update and then distributes it to the domain controllers in the remote domain.

As you can see, only a single copy of the update was transmitted across the WAN link instead of ten separate copies. When implemented correctly, sites can drastically reduce replication-related network traffic.

Troubleshooting replication
Anytime that you make an Active Directory update and the update isn't accessible to those accessing other domain controllers within a reasonable amount of time, there's a chance that you may have a replication problem. For example, imagine that an Administrator creates a new user account. The Administrator then calls the user to say that the new user account should be ready to use within about 20 minutes (after the next replication cycle completes), After about half an hour, the user calls back and says that she can't log in because Windows is telling her that her account doesn't exist. The Administrator checks and, sure enough, the account exists. In this case, the account exists on the domain controller that the Administrator is connected to, but the account has yet to be replicated to the domain controller that is processing the user's login, thus giving the illusion that the account doesn't exist.

If the company only has a few domain controllers, the administrator can actually use the Active Directory Users And Computers console to see which domain controllers the account has been written to. To do so, simply right-click on the domain name and select the Connect To Domain Controller command from the resulting shortcut menu. In doing so, the administrator will be able to connect individually to various domain controllers and see if the new account has been replicated.

This technique works great for small organizations, but what if your domain has 200 domain controllers? You don't want to have to individually check each one. This is where a tool called the Replication Monitor comes in. The Replication Monitor is a tool that allows you to see exactly what is happening with the replication process. It allows you to view the status of Active Directory replication and force replication if necessary.

The Replication Monitor is one of the Windows 2003 Support Tools and, therefore, isn't installed automatically as part of the operating system. (This tool is also included in the Windows 2000 Support Tools.) To install the Windows 2003 Support Tools, insert your Windows 2003 Server CD. Now, open My Computer and browse the CD's contents. Navigate to the CD's \SUPPORT\TOOLS folder, and then run the SUPTOOLS.MSI file.

When installation completes, there will be an option for the Support Tools on the Start | All Programs menu, but the Replication Monitor is not listed on this menu. To open the Replication Monitor, you must go to the \PROGRAM FILES\SUPPORT TOOLS folder and run the REPLMON.EXE file.

When the Replication Monitor opens, you'll see a big, mostly empty screen. This console is divided into two columns. The column on the left simply says Monitored Servers, and the column on the right says Log. In a large organization if all domain controllers were automatically monitored, there would be so much data displayed that it would be very difficult to make sense of it all.

The first time I ever used the Replication Monitor, I was slightly upset that I was unable to automatically monitor all of my domain controllers. After all, I wanted a tool that would tell me where replication was failing, not a tool that would make me guess which server was failing and would then tell me if my guess was right. In a way, though, the Replication Monitor does tell you which server is failing.

Let's go back to the situation in which the Administrator creates a user account but the user can't access the account because it has never been replicated.

In a situation like this, you can use the replication monitor in conjunction with the information that you know to figure out which domain controllers are failing to receive replication updates.

For example, the administrator knows that the domain controller on which he created the account has a copy of the account. The administrator can even find out which domain controller he is connected to by using the Connect To Domain Controller option in the Active Directory Users And Computers console. Upon selecting this option, the console will tell you which domain controller you are currently connected to before asking you which domain controller you would like to connect to.

The other useful tidbit of information in this situation is the user's physical location. By looking at which building the user is located in, the Administrator can determine if the user is trying to authenticate through a domain controller in the same site as the administrator's domain controller or through a domain controller in a remote site. For the sake of argument, let's assume that both the user and the administrator are in the same building and are, therefore, accessing domain controllers in a common site.

In a situation like this, every domain controller in a site sends updates to every other domain controller in the site. The administrator knows that the domain controller he is attached to is functional, so he can tell the Replication Monitor to monitor that domain controller. He can then watch to see which domain controllers fail to be updated. If there is a failure replicating Active Directory information to all of the other domain controllers, then the administrator's domain controller is probably the one with the problem. If, however, only one domain controller fails to receive updates, then that's the domain controller with the problems.

To perform such an operation, right-click on the Monitored Servers container within the Replication Monitor and select the Add Monitored Server command from the resulting shortcut menu. This will cause Windows to display the Add Server To Monitor dialog box. You can either enter the server's name directly or you can select the server from a list. Upon entering the server name, Windows will display the Active Directory in tree form. You will notice in that multiple domains are listed.

Expand the desired domain and you will see the other domain controllers in this domain. If you look at Figure A, you will notice that there is a red X over the icon for server Brien. In this case, I have purposefully taken this server offline so that you can see what a replication failure looks like. If you select the failing server, you can see log information that gives you additional information about the failure.

In a situation like this, the first thing you would want to do is right-click on the failing server, and select the Synchronize With This Replication Partner command from the resulting shortcut menu. When you do, the Replication Monitor will attempt to force replication. Of course, in this case, forcing replication is impossible because the server is down.

Fixing a replication problem
Once you have identified the problem server, the next step is to fix the problem. In every real life replication failure that I have ever seen, the problem was one of three things: the server was down; the server was having trouble with network communications; or the server's hard disk was full.

Therefore, I recommend going to the server and checking out the basics. Make sure that the server has plenty of hard disk space. Next, make sure that you can ping the functional domain controllers. It's important that you be able to ping by both IP address and host name. If you find that you can ping by IP address but not by host name, then it's likely that the machine is having trouble communicating with a DNS server. Make sure that TCP/IP is configured correctly and that the server's designated DNS server is functional.

If everything checks out on the server, but it still can't receive replication updates, you are not completely out of luck. The truth is that there are quite a few less common problems that can cause replication troubles. This is especially true if you are dealing with replication across a site link. For example, when replicating across a site, your designated bridgehead server may be too busy to effectively handle its bridgehead duties. You can find a description of these less common problems and their solutions in Microsoft's TechNet.

Howto Backup IIS 7.0 web server configuration

To backup your IIS 7.0 configuration on a Windows 2008 Server,
you just need to make a copy of the
\windows\system32\inetsrv\config directory (and subdirectories) and save it in a safe location.

You can also use the appcmd.exe utility to create the backup via the command line. The syntax to create a backup is:

%windir%\system32\inetsrv\appcmd.exe add backup “Backup Name”

to restore the backup, the syntax is:

%windir%\system32\inetsrv\appcmd.exe restore backup “Backup Name”

to remove a backup, the syntax is:

%windir%\system32\inetsrv\appcmd.exe delete backup “Backup Name”

How to deploy a MSI on multiple machines by using Group Policy.

1. Methods of deployment

Group Policy supports two methods of deploying a MSI package:

Assign software - A program can be assigned per-user or per-machine. If its assigned per-user, it will be installed when the user logs on. However, if its assigned per-machine then the program will be installed for all users when the machine starts.
Publish software - A program can be published for one or more users. This program will be added to the Add or Remove Programs list and the user will be able to install it from there.

2. Create a distribution point

The first step in deploying a MSI through GPO is to create a distribution point on the publishing server. This can be done by following these steps:

A.log on to the server as an Administrator user
B. create a shared network folder (this folder will contain the MSI package)
C. set permissions on this folder in order to allow access to the distribution package
D. copy the MSI in the shared folder
E. In the shared folder you can also perform an administrative install for a MSI package contained by an EXE bootstrapper.

3. Create a Group Policy Object

A MSI package is deployed (distributed) through GPO as a Group Policy Object. In order to create an object for your package, you can follow these steps:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. select the Group Policy tab and click New
D. set the name of the policy (for example MyApplication)
E. click Properties and select the Security tab
F. check the Apply Group Policy checkbox only for the groups to which the policy will be applied
G. click on the OK button

4. Assign a MSI package

A package can be assigned per-user or per-machine. Also, if the package is assigned, it will automatically be installed silently. In order to assign a package you can follow these steps:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you want and click Edit
D. expand Software Settings under Computer Configuration
E. right-click Software Installation, select the New context menu and then click on Package
in the Open dialog type the full UNC path of the shared package you want to assign
F. click on the Open button
G. click on Assigned and then click OK (the package will be added to the right pane of the "Group Policy" window)
H. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
when the client computers start, the assigned package will be installed automatically
Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

5. Publish a MSI package

When using Group Policy, you can publish a package in order to allow the target user to install it by using Add or Remove programs. The steps for publishing a package are:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you want and click Edit
D. expand Software Settings under User Configuration
E. right-click Software Installation, select the New context menu and then click on Package
in the Open dialog type the full UNC path of the shared package you want to publish
F. click on the Open button
G. click on Publish and then click OK (the package will be added to the right pane of the "Group Policy" window)
H. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in
test the package:
I. log on to the target computer
J. click on the Start button and go to Control Panel
K. double-click the Add or Remove programs applet and select Add New Programs
in the Add programs from your network list select the program you published
use the Add button to install the package
L. click OK and then Close
Do not use the Browse button in the Open dialog to access the UNC location. Make sure that you use the UNC path to the shared package.

6. Redeploy a MSI package

Sometimes you may need to redeploy a package (for example when doing an upgrade). For redeploying a package you can follow these steps:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you used to deploy the package and click Edit
D. expand the Software Settings element (per-user or per-machine) which contains the deployed package
E. expand the Software Installation element which contains the deployed package
F. right-click the package in the right pane of the Group Policy window
G. select the All Tasks menu and click Redeploy application
H. click the Yes button for reinstalling the application wherever it is installed
I. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in

7. Remove a MSI package

Group Policy also allows you to remove packages which have been deployed in the past. Here are the steps for removing a package:

A. click on the Start button, go to Programs, select Administrative Tools and then select Active Directory Users and Computers
B. right-click your domain name in the console tree and select the Properties context menu
C. go to the Group Policy tab, select the object you used to deploy the package and click Edit
D. expand the Software Settings element (per-user or per-machine) which contains the deployed package
E. expand the Software Installation element which contains the deployed package
F. right-click the package in the right pane of the Group Policy window
G. select the All Tasks menu and click Remove
H. select from the following options:
I. Immediately uninstall the software from users and computers
J. Allow users to continue to use the software but prevent new installations
K. click the OK button to continue
L. close the Group Policy snap-in, click OK and exit the Active Directory Users and Computers snap-in

How do I create a MSI wrapper over EXE installation files

In order to exemplify the procedure, we will assume to wrap three .EXE installers "test1.exe", "test2.exe" and "test3.exe" into a .MSI. Here are the steps:

1. In Product Details Tab (Product Details Page) under "Add or Remove Programs (Control Panel)" group, uncheck the "Register product with Windows Installer" option. We don't want the wrapper to appear in "Control Panel" -> "Add or Remove Programs" as an installed program.

2. Go to Files and Folders Page and add the .EXE installers in the "Application Folder".

3. Create a .BAT file with the following content and add it in the Files and Folders Page:

"|InstallPath|test1.exe"
"|InstallPath|test2.exe"
"|InstallPath|test3.exe"

5.  In the same folder, using the toolbar or context menu, create a text file update for the .BAT file. This file update should include a single replace operation:

Find : |InstallPath|
Replace : [APPDIR]
6.  In the Custom Actions Page add the .BAT file as a "Launch File or Open URL" custom action after the "Finish Execution" action group from "Install Execution Stage":

In the "Execution Properties" group on the right page make sure you choose the "Asynchronous execution, do not wait for return" option.
Also enable only the "Install" option from the "Execute Sequence Condition" group.

How do I create a MSI wrapper over EXE installation files

In order to exemplify the procedure, we will assume to wrap three .EXE installers "test1.exe", "test2.exe" and "test3.exe" into a .MSI. Here are the steps:

1. In Product Details Tab (Product Details Page) under "Add or Remove Programs (Control Panel)" group, uncheck the "Register product with Windows Installer" option. We don't want the wrapper to appear in "Control Panel" -> "Add or Remove Programs" as an installed program.

2. Go to Files and Folders Page and add the .EXE installers in the "Application Folder".

3. Create a .BAT file with the following content and add it in the Files and Folders Page:

"|InstallPath|test1.exe"
"|InstallPath|test2.exe"
"|InstallPath|test3.exe"

5.  In the same folder, using the toolbar or context menu, create a text file update for the .BAT file. This file update should include a single replace operation:

Find : |InstallPath|
Replace : [APPDIR]
6.  In the Custom Actions Page add the .BAT file as a "Launch File or Open URL" custom action after the "Finish Execution" action group from "Install Execution Stage":

In the "Execution Properties" group on the right page make sure you choose the "Asynchronous execution, do not wait for return" option.
Also enable only the "Install" option from the "Execute Sequence Condition" group.

Migrating Server 2003 to Server 2008 R2

1. Verify the new server's TCP/IP configuration has been pointed to the current DNS server.

2. Make the new server become a member server of the current Windows Server 2003 domain first.

3. Upgrade the Windows Server 2003 forest schema to Windows Server 2008 schema with the "adprep /forestprep" command on old server.

Please run the "adprep.exe /forestprep" command from the Windows Server 2008 installation disk on the schema master. To do this, insert the Windows Server 2008 installation disk, and then type the following command:

Drive:\sources\ADPREP\adprep.exe /forestprep

4. Upgrade the Windows 2003 domain schema with the "adprep /domainprep" command on old server.

Please run the "adprep.exe /domainprep" command from the Windows Server 2008 installation disk on the infrastructure master. To do this, insert the Windows Server 2008 installation disk, and then type the following command:

Drive:\sources\ADPREP \adprep.exe /domainprep

5. Insert Windows Server 2008 Installation Disc in the new server.

6. Run "dcpromo" on new server to promote it as an additional domain controller in existing Windows 2003 domain, afterwards you may verify the installation of Active Directory.

Please refer to:

How to Verify an Active Directory Installation in Windows Server 2003

http://support.microsoft.com/kb/816106

7. Verify the new server's TCP/IP configuration has been pointed to current DNS server.

8. Enable Global Catalog on new server and manually Check Replication Topology and afterwards manually trigger replication (Replicate Now) to synchronize Active Directory database between 2 replicas.

Please note: It will some time to replicate GC between DC, please wait some time with patience.

9. Disable Global Catalog on the old DC.

10. Transfer all the FSMO roles from the old DC to the new DC.

Please refer to:

How to view and transfer FSMO roles in Windows Server 2003

http://support.microsoft.com/kb/324801

11. Verify that the old DNS Server Zone type is Active Directory-Integrated. If not, please refer to:

How To: Convert DNS Primary Server to Active Directory Integrated

http://support.microsoft.com/kb/816101

Note: Active Directory Integrated-Zone is available only if DNS server is a domain controller.

12. Install DNS component on new server and configure it as a new DNS Server (Active Directory Integrated-Zone is preferred). All the DNS configuration should be replicated to the new DNS server with Active Directory Replication.

13. Make all the clients change TCP/IP configuration to point to new server as DNS.

14. You may configure TCP/IP on all the clients, or adjust DHCP scope settings to make them use the new DNS server.

Logging out from a Remote Desktop Session

When the Remote Desktop Client is exited by pressing the ‘X’ on the control panel the remote session continues to run on the server even though no client is connected. Next time the user connects the desktop session will appear exactly as it was left before.
To end the session select Start in the remote desktop session, click on the right arrow button in the bottom right hand corner of the menu and select Log Off. This will close down the remote desktop session and close the remote desktop client.

How to track users logon/logoff in win 2003

The Auditing

Option 1:

1. Enable Auditing on the domain level by using Group Policy:

      Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy
      There are two types of auditing that address logging on, they are Audit Logon Events and Audit Account Logon Events.

      Audit "logon events" records logons on the PC(s) targeted by the policy and the results appear in the Security Log on that PC(s).

      Audit "Account Logon" Events tracks logons to the domain, and the results appear in the Security Log on domain controllers only


2. Create a logon script on the required domain/OU/user account with the following content:

     echo %date%,%time%,%computername%,%username%,%sessionname%,%logonserver% >>
        \\SERVER\SHARENAME$\LOGON.LOG

3. Create a logoff script on the required domain/OU/user account with the following content:

     echo %date%,%time%,%computername%,%username%,%sessionname%,%logonserver% >>
        \\SERVER\SHARENAME$\LOGOFF.LOG


Note: Please be aware that unauthorized users can change this scripts, due the requirement that

                  the SHARENAME$ will be writeable by users.


Option 2:


Use WMI/ADSI to query each domain controller for logon/logoff events.

20 Tips for Success Learn Programming

Here are tips on how to be successful in learning the programming so it can be a reliable programmer. These tips are the result of discussion and a collection of inputs from various sources programmer friend.

20 Tips to success is as follows:

1.     The initial capital is the motivation to learn programming. If the motivation to learn a great motivation, Congratulations! You are a candidate a reliable programmer. The next focus is to hone the skill to learn programming. Continue to maintain the motivation that has been owned. Do not let this motivation faded as a fiasco.
2.     Do not give up easily. It is not easy to learn programming. It takes struggle, hard work, and experience (flight hours). Do not give up easily when a lot of errors that arise when making program.
3.     Never assume that programming is entirely subject 'memorize'. It's true, is also required to memorize when memorize the syntax and rules of writing in the program. But in principle, programming is a logical way of thinking and learning how to solve the problem.
4.     Do not just be typists. When the teacher gives an example program in the classroom or when practical, do not just look at every line of code such as the wind and you just move it to paper or computer. If only such, as well as learning to be a handyman type. Try to understand every line of code is written and the plot program teacher or your professor. If you already know, try to write his own version of the program according to the book or the computer. If this is done, it is not aware of having to train logical thinking and logical thinking to learn how to express in the form of the program.
5.     To support learning, try to find people who want to teach. When encountering a problem in learning programming. Can be close friends, friends on the internet or even teachers and lecturers, or anybody close to and understand the terms in question.
6.     Do not rely on face to face in the classroom. The material is very extensive programming. What is given when a college professor is very small in scope compared to the overall knowledge of programming. Try exploration own everything about programming. There are many references on the internet that discuss tips and tricks, and techniques in programming.
7.     Look for the focus to the programming community. On the internet there are many discussion forums via the web or mailing list that discusses about the programming. Remember that people often associate with the perfume seller and he will come to be fragrant. So, we adopt this, along with many-many people in the community are equally interest in programming.
8.     It is advisable to have your own computer at home or in boarding. As I mentioned above that in order to master the programming takes experience and a lot of flying hours in the make program. If you do not have your own computer, how to increase flying hours? To learn programming should not need a computer with a high specification. Pentium III computer enough that it can, but study programs that do need such a large specification-based visual programan. Anyway, do not ever rely on hours of practicum in the lab because of time-use is very limited. Think of it as buying a computer is as long-term investment. Rest assured when the capital to buy a computer it will come back again, or instead will provide a return on investment is much greater.
9.     Do not just rely on notes or modules provided by the lecturer. The module content was written by professors on average is still little content. Try to find themselves linked to the programming reference. After all, it's been a lot of books to review on programming. If you want a free, try searching for references on the internet because there are many free ebook can be downloaded.
10.     As pemrogrammer must always remember the almighty, so do not forget to keep pilgrimage. Knowledge come from The Creator, the closer you are to God, the more useful and enjoy doing programming.
11.     A programmer must be set (programmed) its self - self programming. In terms of his personality, for example: when to eat, when to sleep, when to pray, and when the time to gather with family - no coding continues. programming time as well.
12.     A programmer should be able to maintain the health. Because logic can not walk without the logistics, so food must also be considered, regular and nutritious food to the brain so we can think clearly and intelligently.
13.     Do not just focus to benefit themselves. Such programmers are programmers who selfishly. Because one day he must know the talent which he used, should be useful to others.
14.     Like a scientist, programmers must also continue to look for problems in a program and find the solution to the problem.
15.     Begin to learn programming with logics solid foundation. A programmer must always be able to solve problems and provide solutions as long as it is logic, except for the magic-magic forget it, for example: move the Monas to papua / tamanmini move into the pocket.
16.     Do not be afraid to fail. Every programmer must have experienced difficulties / even a failure in completing a project. Maybe, that's the way to success. Which indirectly without you knowing it.
17.     Take a moment to refresh the brain, mind and strength. Not infrequently programmer stress, the brain systems work too hard without regular breaks, because the deadline.
18.     Do not be afraid to "copy paste". No coding required a programmer to write the manual. Besides, to shorten the time, here are a programmer in demand to develop creativity. Many or even most of every programmer uses a variety of templates.
19.     Do not just copy paste from. The average person that the origin copy and paste the program does not try to understand the program that he copy. Try to understand first program obtained mainly on the algorithm, if I could rewrite the program according to your version. May still copy and paste, the origin is also trying to understand the meaning of the program in it. Hopefully if you modify the source code.
20.     Do not forget to practice it. Because science is not practiced like a fruitless tree, share (the study will not be discharged even though divided on how many people) even with a science degree we will be lifted.
     
    Okay all, good luck and practice the above tips ;-)

Error “Some Controls are not valid” while uninstalling Exchange 2010 Management Tools

Error “Some Controls are not valid” while uninstalling Exchange 2010 Management Tools

Recently I faced an issue with uninstalling the Exchange 2010 Management Tool from my Windows 7 Workstation. This error occurred when I was trying to uninstall the Exchange Management Console:
“Some Controls are not valid- Please specify an existing server role(s) to uninstall”

Actually i was not un-checking the “Management Tools” option. I spent lot of time figuring out this..hence thought to share here which may be helpful for others…I hope this saves some time of them.

How to Export Members of Exchange Distribution List

How to Export Members of Exchange Distribution List

I came across this nice VB script to export the list of members of a distribution list of exchange :
'Script begins here
Dim objGroup, objUser, objFSO, objFile, strDomain, strGroup, Domain, Group
'Change DomainName to the name of the domain the group is in
strDomain = Inputbox ("Enter the Domain name", "Data needed", "Default domain name")
'Change GroupName to the name of the group whose members you want to export
strGroup = InputBox ("Enter the Group name", "Data needed", "Default group name")
Set objFSO = CreateObject("Scripting.FileSystemObject")
'On the next line change the name and path of the file that export data will be written to.
Set objFile = objFSO.CreateTextFile("C:\Bin\" & strGroup & " - Members.csv")
Set objGroup = GetObject("WinNT://" & strDomain & "/" & strGroup & ",group")
For Each objUser In objGroup.Members
    objFile.WriteLine objUser.Name & " - " & objUser.Class
Next
objFile.Close
Set objFile = Nothing
Set objFSO = Nothing
Set objUser = Nothing
Set objGroup = Nothing
Wscript.Echo "Done"
Wscript.Echo "Please check the c: for your output file"
Note: The script will ask you the domain name and the group the distribution group for which member list to be created.

How to migrate .pst and .ost through USMT 4.0?

How to migrate .pst and .ost through USMT 4.0?

By default, USMT 4.0 migrates PST files that are linked to a user’s outlook profile and does not copy those PST which are not attached with profile. USMT does not support .ost migration. E.g. PST’s stored on local drive but not actually attached to outlook will not migrate by default.

In order to migrate PST files, here is the working script which will gather all PST files from all fixed drives:

 

    All PST migrated from all fixed drives, regardless of location

   

     

       

         

           

         

       

     

   

 

Paste this script into notepad and save as PST.xml. Now, the main idea behind this script is that it should be saved in System 32 folder before running Task sequence. Create a script that will copy the PST.XML file in %System 32% folder of the system and add /i:pst.xml switch to scan state and load state.

This worked fine for me and we have upgraded our whole environment from XP to Windows 7.