you can have you pc out off resources (sockets)
you may need to decrease the timeout for watting to permanently close the sockets.
To do that you can use the parameter in registry TcpTimedWaitDelay.
See the following:
http://msdn.microsoft.com/en-us/library/ms819739.aspx
Wednesday, April 28, 2010
Thursday, April 15, 2010
Outlook, auto mark as read after selection
When you select a message in outllok it becomes automatically "marked as read".
You can change some features related to it in:
Tools menu > Options > Other tab > Reading Pane button
You have some available options very self explainable.
Check or uncheck as best fits your requirements.
“Mark items as read when viewed in the Reading Pane”.
You might also want to change the number of seconds in this dialog.
“Mark item as read when selection changes”
You can change some features related to it in:
Tools menu > Options > Other tab > Reading Pane button
You have some available options very self explainable.
Check or uncheck as best fits your requirements.
“Mark items as read when viewed in the Reading Pane”.
You might also want to change the number of seconds in this dialog.
“Mark item as read when selection changes”
Monday, March 8, 2010
You may not have permission to use this network resource.
Method 1: Enable NetBIOS over TCP/IP and start the Computer Browser service
To resolve this issue, make sure that NetBIOS over TCP/IP is turned on and that the Computer Browser service is running on each computer in the workgroup. To do this, follow these steps.
Step 1: Enable NetBIOS over TCP/IP
1. Click Start, click Control Panel, and then click Network and Internet Connections.
2. Click Network Connections.
3. Right-click Local Area Connection, and then click Properties.
4. Click Internet Protocol (TCP/IP), and then click Properties.
5. Click the General tab, and then click Advanced.
6. Click the WINS tab.
7. Under NetBIOS setting, click Enable NetBIOS over TCP/IP, and then click OK two times.
8. Click Close to close the Local Area Connection Properties dialog box.
9. Close the Network Connections window.
Step 2: Start the Computer Browser service
1. Click Start, right-click My Computer, and then click Manage.
2. Double-click Services and Applications.
3. Double-click Services.
4. On the right side, right-click Computer Browser, and then click Start.
5. Close the Computer Management window.
Method 2: Install File and Print Sharing and make sure that it is not blocked by Windows Firewall
Step 1: Install File and Print Sharing for Microsoft Networks
1. Click Start, click Run, type ncpa.cpl, and then click OK.
2. Right-click Local Area Connection, and then click Properties.
3. Click the General tab, and then click Install.
4. Click Service, and then click Add.
5. In the Network Service list, click File and Print Sharing for Microsoft Networks, and then click OK.
6. Click Close.
Step 2: Make sure that File and Printer Sharing is not blocked by Windows Firewall
1. Click Start, click Run, type firewall.cpl, and then click OK.
2. On the General tab, make sure that the Don't allow exceptions check box is not selected.
3. Click the Exceptions tab.
4. On the Exceptions tab, make sure that the File and Printer Sharing check box is selected, and then click OK.
To resolve this issue, make sure that NetBIOS over TCP/IP is turned on and that the Computer Browser service is running on each computer in the workgroup. To do this, follow these steps.
Step 1: Enable NetBIOS over TCP/IP
1. Click Start, click Control Panel, and then click Network and Internet Connections.
2. Click Network Connections.
3. Right-click Local Area Connection, and then click Properties.
4. Click Internet Protocol (TCP/IP), and then click Properties.
5. Click the General tab, and then click Advanced.
6. Click the WINS tab.
7. Under NetBIOS setting, click Enable NetBIOS over TCP/IP, and then click OK two times.
8. Click Close to close the Local Area Connection Properties dialog box.
9. Close the Network Connections window.
Step 2: Start the Computer Browser service
1. Click Start, right-click My Computer, and then click Manage.
2. Double-click Services and Applications.
3. Double-click Services.
4. On the right side, right-click Computer Browser, and then click Start.
5. Close the Computer Management window.
Method 2: Install File and Print Sharing and make sure that it is not blocked by Windows Firewall
Step 1: Install File and Print Sharing for Microsoft Networks
1. Click Start, click Run, type ncpa.cpl, and then click OK.
2. Right-click Local Area Connection, and then click Properties.
3. Click the General tab, and then click Install.
4. Click Service, and then click Add.
5. In the Network Service list, click File and Print Sharing for Microsoft Networks, and then click OK.
6. Click Close.
Step 2: Make sure that File and Printer Sharing is not blocked by Windows Firewall
1. Click Start, click Run, type firewall.cpl, and then click OK.
2. On the General tab, make sure that the Don't allow exceptions check box is not selected.
3. Click the Exceptions tab.
4. On the Exceptions tab, make sure that the File and Printer Sharing check box is selected, and then click OK.
Monday, December 7, 2009
Event Viewer - vc80.mfcloc could not be found
When you start Microsoft Dynamics CRM 3.0 Mobile Deployment Manager on a Microsoft Dynamics CRM server, the following event IDs are logged in the event log.
Event ID: 32
Source: SideBySideEvent ID: 32 Description: Dependent Assembly Microsoft.VC80.MFCLOC could not be found.
Event ID: 59
Source: SideBySideEvent ID: 59 Resolve Partial Assembly failed for Microsoft.VC80.MFCLOC. Reference error message: The referenced assembly is not installed on your system.
Event ID: 59
Source: SideBySideEvent ID: 59 Generate Activation Context failed for C:\WINDOWS\system32\MFC80U.DLL. The referenced assembly is not installed on your system.
Please check:
http://support.microsoft.com/kb/923014/en-us
Event ID: 32
Source: SideBySideEvent ID: 32 Description: Dependent Assembly Microsoft.VC80.MFCLOC could not be found.
Event ID: 59
Source: SideBySideEvent ID: 59 Resolve Partial Assembly failed for Microsoft.VC80.MFCLOC. Reference error message: The referenced assembly is not installed on your system.
Event ID: 59
Source: SideBySideEvent ID: 59 Generate Activation Context failed for C:\WINDOWS\system32\MFC80U.DLL. The referenced assembly is not installed on your system.
Please check:
http://support.microsoft.com/kb/923014/en-us
Wednesday, November 4, 2009
Using Group Policy to Deploy Applications
Before We Begin
The technique that I’m about to show you will allow you to deploy applications through the Active Directory. One of the major limitations behind this type of application deployment is that you can only use this technique to deploy certain types of applications. Specifically, you can install Windows Installer packages (.MSI files), Transform Files (.MST files), and patch files (.MSP files).
Creating MSI Files
Windows does not natively contain the necessary tools for you to create your own MSI files. Instead, you will have to rely on a third party MSI creation tool. There are several good tools available for free. Two of the more popular choices are MAKEMSI (http://dennisbareis.com/makemsi.htm) and WinInstall LE 2003 (http://www.ondemandsoftware.com/freele.asp).
Being that I’ve never been a big fan of script writing, I prefer to use the WinInstall LE tool to create MSI files. It doesn’t require any scripting, but it is a little time consuming to use. WinInstall LE requires you to have a machine with a clean Windows installation and network connectivity. The software then takes a snapshot of this machine and saves the configuration image. You would then install the application that you want to create the MSI file for and take another snap shot. WinInstall would then compare the snapshots and use the differences between the two images to create an MSI file and the corresponding installation package.
This method is a little time consuming, but is far less tedious than writing scripts. Another advantage to using this method is that it is possible to install multiple applications on to the clean machine prior to taking the second snap shot. This means that you can create a single MSI file and installation package that deploys multiple applications.
Publishing and Assigning Applications
Now that you know how to create an MSI file, there is one last concept that I need to talk about before I show you how to deploy an application thorough the Active Directory.
As you may already know, in an Active Directory environment, group policies are the main component of network security. Group policy objects can be applied either to users or to computers. Deploying applications through the Active Directory is also done through the use of group policies, and therefore applications are deployed either on a per user basis or on a per computer basis.
There are two different ways that you can deploy an application through the Active Directory. You can either publish the application or you can assign the application. You can only publish applications to users, but you can assign applications to either users or to computers. The application is deployed in a different manner depending on which of these methods you use.
Publishing an application doesn’t actually install the application, but rather makes it available to users. For example, suppose that you were to publish Microsoft Office. Publishing is a group policy setting, so it would not take effect until the next time that the user logs in. When the user does log in though, they will not initially notice anything different. However, if the user were to open the Control Panel and click on the Add / Remove Programs option, they will find that Microsoft Office is now on the list. A user can then choose to install Microsoft office on their machine.
One thing to keep in mind is that regardless of which deployment method you use, Windows does not perform any sort of software metering. Therefore, it will be up to you to make sure that you have enough licenses for the software that you are installing.
Assigning an application to a user works differently than publishing an application. Again, assigning an application is a group policy action, so the assignment won’t take effect until the next time that the user logs in. When the user does log in, they will see that the new application has been added to the Start menu and / or to the desktop.
Although a menu option or an icon for the application exists, the software hasn’t actually been installed though. To avoid overwhelming the server containing the installation package, the software is not actually installed until the user attempts to use it for the first time.
This is also where the self healing feature comes in. When ever a user attempts to use the application, Windows always does a quick check to make sure that the application hasn’t been damaged. If files or registry settings are missing, they are automatically replaced.
Assigning an application to a computer works similarly to assigning an application to a user. The main difference is that the assignment is linked to the computer rather than to the user, so it takes effect the next time that the computer is rebooted. Assigning an application to a computer also differs from user assignments in that the deployment process actually installs the application rather than just the application’s icon.
Deploying Applications
Setting up the actual deployment is simple. The biggest thing that you must remember is that the MSI file and the corresponding package must exist within a network share, and everyone must have read permissions for that share.
To perform the deployment, open the Group Policy Editor. To publish or assign an application to a user, navigate through the group policy console to User Configuration Software Settings Software Installation. Now, right click on the Software Installation container and select the New Package commands from the shortcut menu. Select the appropriate MSI file and click Open. You are now asked whether you want to publish or assign the application. Make your selection and click OK.
The process for assigning an application to a computer is almost identical. The only real difference is that you would use the Software Settings Software Installation container beneath the Computer Configuration container rather than beneath the User Configuration container.
See also (for unatended installation):
http://unattended.sourceforge.net/installers.php
The technique that I’m about to show you will allow you to deploy applications through the Active Directory. One of the major limitations behind this type of application deployment is that you can only use this technique to deploy certain types of applications. Specifically, you can install Windows Installer packages (.MSI files), Transform Files (.MST files), and patch files (.MSP files).
Creating MSI Files
Windows does not natively contain the necessary tools for you to create your own MSI files. Instead, you will have to rely on a third party MSI creation tool. There are several good tools available for free. Two of the more popular choices are MAKEMSI (http://dennisbareis.com/makemsi.htm) and WinInstall LE 2003 (http://www.ondemandsoftware.com/freele.asp).
Being that I’ve never been a big fan of script writing, I prefer to use the WinInstall LE tool to create MSI files. It doesn’t require any scripting, but it is a little time consuming to use. WinInstall LE requires you to have a machine with a clean Windows installation and network connectivity. The software then takes a snapshot of this machine and saves the configuration image. You would then install the application that you want to create the MSI file for and take another snap shot. WinInstall would then compare the snapshots and use the differences between the two images to create an MSI file and the corresponding installation package.
This method is a little time consuming, but is far less tedious than writing scripts. Another advantage to using this method is that it is possible to install multiple applications on to the clean machine prior to taking the second snap shot. This means that you can create a single MSI file and installation package that deploys multiple applications.
Publishing and Assigning Applications
Now that you know how to create an MSI file, there is one last concept that I need to talk about before I show you how to deploy an application thorough the Active Directory.
As you may already know, in an Active Directory environment, group policies are the main component of network security. Group policy objects can be applied either to users or to computers. Deploying applications through the Active Directory is also done through the use of group policies, and therefore applications are deployed either on a per user basis or on a per computer basis.
There are two different ways that you can deploy an application through the Active Directory. You can either publish the application or you can assign the application. You can only publish applications to users, but you can assign applications to either users or to computers. The application is deployed in a different manner depending on which of these methods you use.
Publishing an application doesn’t actually install the application, but rather makes it available to users. For example, suppose that you were to publish Microsoft Office. Publishing is a group policy setting, so it would not take effect until the next time that the user logs in. When the user does log in though, they will not initially notice anything different. However, if the user were to open the Control Panel and click on the Add / Remove Programs option, they will find that Microsoft Office is now on the list. A user can then choose to install Microsoft office on their machine.
One thing to keep in mind is that regardless of which deployment method you use, Windows does not perform any sort of software metering. Therefore, it will be up to you to make sure that you have enough licenses for the software that you are installing.
Assigning an application to a user works differently than publishing an application. Again, assigning an application is a group policy action, so the assignment won’t take effect until the next time that the user logs in. When the user does log in, they will see that the new application has been added to the Start menu and / or to the desktop.
Although a menu option or an icon for the application exists, the software hasn’t actually been installed though. To avoid overwhelming the server containing the installation package, the software is not actually installed until the user attempts to use it for the first time.
This is also where the self healing feature comes in. When ever a user attempts to use the application, Windows always does a quick check to make sure that the application hasn’t been damaged. If files or registry settings are missing, they are automatically replaced.
Assigning an application to a computer works similarly to assigning an application to a user. The main difference is that the assignment is linked to the computer rather than to the user, so it takes effect the next time that the computer is rebooted. Assigning an application to a computer also differs from user assignments in that the deployment process actually installs the application rather than just the application’s icon.
Deploying Applications
Setting up the actual deployment is simple. The biggest thing that you must remember is that the MSI file and the corresponding package must exist within a network share, and everyone must have read permissions for that share.
To perform the deployment, open the Group Policy Editor. To publish or assign an application to a user, navigate through the group policy console to User Configuration Software Settings Software Installation. Now, right click on the Software Installation container and select the New Package commands from the shortcut menu. Select the appropriate MSI file and click Open. You are now asked whether you want to publish or assign the application. Make your selection and click OK.
The process for assigning an application to a computer is almost identical. The only real difference is that you would use the Software Settings Software Installation container beneath the Computer Configuration container rather than beneath the User Configuration container.
See also (for unatended installation):
http://unattended.sourceforge.net/installers.php
Subscribe to:
Posts (Atom)