Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Vista

Understanding the Capabilities of Windows Installer (part 2) - Managing the Windows Installer service

- Windows 10 Product Activation Keys Free 2019 (All Versions)
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
11/8/2011 9:26:57 AM

2. Managing the Windows Installer service

As you can see, there's a lot to the basic Windows Installer architecture. Now that you understand that Windows Installer is a transactional service that is based on the MSI database, you're starting to see the value of such a service in a managed network. Because Windows Installer is a service, it needs to be managed like all the other components in your network. Microsoft has made it easy to work with and manage this service. As mentioned previously, much of the service administration is performed through the msiexec.exe command. However, Microsoft has also given you the ability to centrally manage the behavior of the service through Group Policy Objects (GPO) and Active Directory.

Working with Windows Installer installations

Because it is a service, Windows Installer runs under the Local System account privilege. This means that it has the right to perform almost any installation operation even if users are in a locked-down environment. Note that you may control if and how the ability to run installations with elevated privileges should be handled via Group Policy (refer to the AlwaysInstallElevated policy). There are several ways to start this service, but they are all related to a Windows Installer or MSI installation. Without the MSI, you cannot access the service. This means you can launch a Windows Installer operation using any of the following actions:

  • Double-click setup.exe for an MSI-based installation

  • Double-click an MSI file

  • Use the msiexec.exe command

  • Use Add/Remove Programs

  • Deploy an MSI product through Group Policy or through a software deployment tool that understands MSIs

When an interactive installation is initiated, it calls upon the Windows Installer application-programming interface (API) to start the service and present the appropriate dialog boxes to the user. To do this, the service runs several processes, one in your user context with your user rights and permissions and others in the Local System account context. This is why it is best to deploy MSIs centrally: even if WIS has access to the Local System account, if your credentials do not allow you to perform installations, you won't be able to install a product interactively. On the other hand, if you deploy the installation with the appropriate settings the service will be able to perform the installation even if the logged-on user does not have installation rights. In this case, the processes that run in the user context are only run to configure actual user settings and not to install the application. Remember that the user has complete control over the user profile so running in the user context allows WIS to complete installations properly.

One key element of an MSI installation is context. You can work with Windows Installer to deploy applications on either a per user or per machine basis. Using the ALLUSERS=1 property during installation will tell Windows Installer to perform a machine-based installation or an installation that will configure settings within the All Users profile, letting any user who has access to the machine have access to the installation. In most if not all cases, you'll want to use per machine installations. That's because if you install an application on a per user basis, only the user who installed the application can remove it from the system because only that user has access to the user profile in which the application hooks reside. If multiple users installed the same application on a per user basis, then it cannot be removed until each user has uninstalled it. In managed environments, this can be quite a headache.

NOTE

The default installation that Windows Installer performs is a per user installation. That's because by default, the ALLUSERS property is not set and a user installation is the default behavior. Make sure that you change this value. As mentioned above, the value can be set directly within your own packages, can be modified through a transform, or can be added to the command line while installing a product.

There are a couple of possible values that may be assigned to the ALLUSERS property, and they can mean different things based on the rights of the individual performing the installation:

ALLUSERS = 1 (All Users)

If the user performing the installation is a standard user, the above will return an error as an unprivileged user does not have sufficient permission to install an application for all users. If the user has admin privileges, the installation will be performed for all users (to the "All Users" profile directory):

ALLUSERS = 2 (Current User)

While you would expect setting ALLUSERS to 2 would always install just for the current user, if the user has administrative privileges it will be installed for all users even if this setting is specified. If you really do want to install just for the current user and have administrative privileges, this property should not be set at all so the default behavior of installing just for the current user may be realized.

During the installation, Windows Installer will back up any file it replaces in order to support installation rollback. These files are copied to a temporary folder, often the c:\config.msi folder. Of course, once the installation is complete, it removes the files.

In addition, when it finishes an installation, WIS will copy the installation's MSI file and any associated MST file to a special folder called %windir%\installer and rename it with a cryptic name. This allows it to manage the installed product directly from the local machine without necessarily requiring access to the original installation source (see Figure 4).

NOTE

The %windir%\installer folder is a hidden folder by default. To view it, type the address in Windows File Explorer. In addition, you'll notice that all of the filenames are very cryptic. To view which product the file matches to, right-click the Explorer sort bar at the top of the Details pane and add both Title and Author to the detailed view. This will show you which manufacturer and to which product the file relates.

Alternatively, you can simply hover over the file in Windows File Explorer to see its properties in a tooltip.

Figure 4. Understanding how the components work together during a product installation

Leveraging GPO settings and policies

Corporate networks that run Active Directory can centrally control the Windows Installer service through Group Policy. If you don't have Active Directory, then you'll have to use another centralized management tool to control these settings or you'll have to do it through local policies.

There are quite a few policy settings for the Windows Installer service, especially after Server 2003 Service Pack 2. Table 4.2 outlines all of these settings and indicates some recommended settings for them as provided with Server 2008. All specific settings for Windows Installer are found by choosing Computer Configuration Policies Administrative Templates Windows Components Windows Installer or User Configuration Policies Administrative Templates Windows Components Windows Installer. Software deployment settings are located in either Computer Configuration Policies Software Settings Software Installation or User Configuration Policies Software Settings Software Installation. In most cases, you'll want to work with the Computer Configuration portion of a Group Policy because you want to avoid user-based software deployments as much as possible.

NOTE

Networks running Windows XP Service Pack 2 and Windows Server 2003 but without Service Pack 1 for Windows Server 2003 need to add a special hotfix for Windows Server. This hotfix allows you to open policies either from Windows Server or from Windows XP with no error. This is described in article number 842933 on the Microsoft Knowledge Base. It can be downloaded from here: http://support.microsoft.com/default.aspx?kbid=842933.

In addition, tow with the admin template files that are contained in Windows XP Service Pack 2, you need to run the Group Policy Management Console (GPMC) from a machine running XP SP2 and open each of the policies you want updated. This automatically adds the appropriate admin template files to the policies.

Table 2. Group Policy Settings for Windows Installer
Group Policy SettingPurposeRecommended SettingNotes
Computer Configuration => Policies => Administrative Templates => Windows Components => Windows Installer
Disable Windows InstallerControls the use of Windows InstallerNot configured in Windows Server 2003 and later In Windows 2000 Server networks, change to For non-managed apps only.This setting ensures only deployed software can be installed by normal users. This is the default in Windows Server 2003 and later.
Always install with elevated privilegesTells WIS to use system credentials to install softwareNot configuredWhen you have a systems management solution in place there is no need for this setting (the solution's own agent is used instead).
Prohibit Use of Restart ManagerControls if Restart Manager should detect files and use and mitigate a system restart when possibleNot configuredEnabled by default, this feature is new to Vista and later systems and can reduce the need for system restarts due to in-use files.
Prohibit rollbackStops WIS from creating temporary files for rollbackNot configuredThe only reason to enable this setting is to save temporary disk space. Do not use this setting in either Computer or User Configuration because setting it in one automatically turns it on for the other.
Remove browse dialog box for new sourceStops users from browsing the file system when installing features in WISNot configuredThe default behavior is sufficient in this case.
Prohibit patchingStops users from patching WIS productsNot configuredBy default, only administrators can patch products.
Prohibit Flyweight PatchingControls the ability to turn off all patch optimizationsNot configuredBy default, installations will be automatically analyzed to determine if optimization is possible.
Prohibit removal of updatesProtects updates from being removedNot configuredBy default, only administrators can remove updates.
Disable IE security prompts for Windows Installer scriptsLets Web-based programs install without user knowledgeNot configuredApplying this can be a very high security risk.
Enable user control over installsGives users elevated privileges during installationsNot configuredUsers should not have the right to install software except under special situations. In this case, there are better ways to give them these rights than this policy.
Enable user to browse for source while elevatedGives users access to restricted files and foldersNot configuredThis would let users use the Local System account to access restricted files and folders during an installation. It is turned off by default.
Enable user to use media source while elevatedGives users access to removable media during installations with high privilegesNot configuredUsers can access removable media during installations in their own security context. Since you want only per machine installs, do not enable this setting.
Enable user to patch elevated productsGives users the ability to patch software, even when running with elevated privilegesNot configuredPatches should be delivered centrally to end users.
Allow admin to install from Terminal Services sessionLets administrators install applications when in a TS sessionEnabledThis affects only system administrators and lets them install software through Terminal Services sessions.
Cache transforms in secure location on workstationSaves transforms in secure location on the desktopNot configured on Windows Server 2003 and later Enabled on Windows 2000 ServerCaching transforms into secure locations protects them from malicious tampering. This is the default behavior in Windows Server 2003 and later. This is also key to per machine installs because transforms can only be used on the same machine when this setting is enabled.
LoggingSets the logging level for WISNot configuredUse this only when required. Logs are saved to the Temp folder of the system volume. While logging is available at the command line, for deployments via Group Policy this can prove a valuable feature. When enabled, default logging is set to include status messages, warnings, error messages, start up of actions, and terminal properties.
Disable logging via package settingsControls if MSI packages may be authored to dictate their own logging settingsEnabled Set to Disable logging via package settings onNormally, you specify logging at the command line or for all installations via the Logging policy (above). This keeps setup authors from being able to dictate logging behavior via the MsiLogging property
Prohibit user installsControls how user installs are configuredEnabled Set to Hide User InstallsThis setting will prevent per user installations and allow only per machine installations. Note: On Windows 2000, this setting disables all installs.
Turn off creation of System Restore CheckpointsProtects user systems by creating restore points on Windows XP and later systemsNot configuredThis setting is enabled by default.
Enforce upgrade component rulesControls how upgrades occurNot configuredIf this setting is enabled, some upgrades may fail because you will have to follow strict upgrade rules. It is not always possible to control how upgrades are performed because you do not always control the source code for the upgrades.
Prohibit non-administrators from applying vendorsigned updatesControls the ability of non-administrators to install updates that have been digitally signed by the application vendorNot configuredBy default, updates that are properly signed by vendors can be installed by users.
Baseline file cache maximum sizeControls the percentage of disk space available for the baseline cacheNot configuredBy default, Windows Installer uses 10 percent of available free space for this cache. Change it only if you feel 10 percent is not sufficient for your needs.
Always install with elevated privilegesTells WIS to use system credentials to install softwareNot configuredWhen you have a proper MSI deployment tool in place, there is no need for this setting.
Search orderTells WIS where to search for installation filesNot configuredBy default, WIS searches the network first, then removable media, then the Internet.
Prohibit rollbackStops WIS from creating temporary files for rollbackNot configuredThe only reason to enable this setting is to save temporary disk space. Do not use this setting in either Computer or User Configuration because setting it in one automatically turns it on for the other.
Prevent removable media source for any installControls if users can install software from removable mediaEnabledThis setting stops users from being able to install software from removable media. Ideally, software should be installed from the network only. Even if it is enabled, administrators can install from any location.
User Configuration => Policies => Administrative Templates => Control Panel => Add or Remove Programs
Hide the Add a program from CD-ROM or floppy disk optionLets users add programs from removable media through the Control PanelEnabledThis setting is used in conjunction with the "Prevent removable media source for any install" setting. Note: You might want to enable the Hide Add new Programs page as this will stop users from adding programs through the Control Panel.

Make sure that you apply the settings from Table 2 to your production network and that you include testing computers with these settings in your packaging lab. Doing this lets you test as a user under full user conditions when preparing packages. As for software delivery through Group Policy, it is recommended that you only use the Computer Configuration portion of the GPO because you want to ensure all installs be on a per machine basis.

Implementing software restriction policies

To protect your systems further from unwanted software installations, you should make use of Windows' Software Restriction Policies (SRP). SRPs are designed to help control the execution of code within your network. SRPs rely on four different rules to determine if software can execute in the network. These rules include:

  • Hash rule: A hash is a special identifier that is generated by performing calculations on the binary elements of a file. Because of the way the hash is calculated, no two-hash rules are the same. It is also impossible to reverse the process to find the originating data. To use hash rules, you need a hash-generating program.

  • Certificate rule: A public key certificate that is included in both the SRP rule and in the MSI packages. This is often the easiest way to use SRP because it is easier for you to control certificates, especially because Windows Server 2003 includes the ability to manage an internal public key infrastructure (PKI).

  • Path rule: One of the simplest SRP rules because it simply states which paths are acceptable to host application setup packages. Be careful if you use this method because if you allow *\softwaresource\* for example, anyone can create a program that makes the C:\softwaresource folder and run program installations from there. The best way to use this rule type is to implement a distribution structure based on the Distributed File System (DFS) that can present the same installation source to all sites through DFS Namespaces.

  • Internet zone rule: This rule is based on the zones perceived by Internet Explorer. This method is slightly more risky because after a zone is allowed, any installations from this zone will work.

Rules are applied in the order they are listed here. Often the easiest way to implement SRPs is to combine both a certificate rule with a path rule based on DFS Namespaces. Because DFS Namespaces use the domain name in the universal naming convention (UNC) rather than the server name, the same path can be used anywhere in the network.

If you decide to use certificate rules, you'll want to pre-deploy the certificates you will use in your packages. That's because when you deploy a package with an untrusted certificate, the user will have to accept the certificate before the installation can proceed. If on the other hand you have pre-deployed the certificate, then the installation can proceed uninhibited. Fortunately, Windows Server 2003 and later support certificate auto-enrollment. Therefore, users will not even be aware of the need for or the issue of certificates for software deployment and installation.

You might also consider the following:

  • Administrative installations of MSI packages may change the nature of the package so it is always best to install a certificate in the package after it has been installed to the administrative location.

  • Commercial MSI packages may also already include digital signatures. In this case, you can add the vendor's certificate to your SRP rules. If you modify the package once deployed, it needs to be re-signed.

  • Make sure that your certificates are managed properly and accessible to anyone who needs to sign packages that are ready for deployment.

When you set up SRP, you'll need to first generate the SRP objects in the Group Policy you will use to manage them. These objects are not generated by default within GPOs. Next, determine how it will be enforced. It is best to enforce to all software except libraries (for example DLLs) and to all users. This way, administrators are not affected. You'll also want to configure how trusted publishers will be evaluated. It is a good idea To Whom It May Concern: re-verify certificates before allowing the publisher to be trusted. This way, you won't allow publishers with outdated certificates to be trusted.

Managing source lists

Another aspect of MSI package deployment that you need to take into consideration is the installation source list. When you deploy an MSI package, Windows Installer needs to maintain the ability to access the original deployed package source for several reasons. One of the main reasons is package self-healing. During the self-healing process, Windows Installer has to connect to the original installation source to reinstall each feature that has a missing or damaged key path. If the original source is no longer available, WIS will ask the user to provide it with an appropriate location. This is definitely not something you want users to face because they have no idea where these files should be. As you know, many of them will still attempt to resolve this situation themselves before they think to call the Help Desk.

Another example is the product upgrade. In some cases, you may upgrade a product that requires access to the original source installation of the previous version in order to remove it properly. A third example is the installation of companion products. For example, if you install a third-party grammar checker in Microsoft Office, it might require access to the original Office installation files to add features that were not originally selected during install.

All of these situations can cause an installation to fail if source lists are not properly managed. Some good news came with the arrival of Windows Installer version 3.1, which mitigates the impact of these situations because it leverages the locally stored MSI file (in the %windir%\installer folder) to patch and upgrade products. Despite this, it is still very important to maintain constant source lists. The SOURCELIST public property can be used to specify more than one source, and Windows Installer will try all locations listed before prompting the user with a request for a valid location. In addition, the way WIS searches for valid locations is controlled through the search order GPO setting in user configurations. By default, WIS searches the network first, then removable media, then the Internet. The key to source list management is to make sure sources are available before WIS needs to verify their location. From the command line, the SOURCELIST public property can specify one or more paths separated by a semicolon as shown in the following example:

msiexec.exe /i \\server\share\folder\package.msi SOURCELIST="\\dfspath\
der\;c:\localsource;http://installationpoint.com/acnt"

There are a couple of ways to deal with source list management. One is to design a proper package delivery infrastructure in your network. As mentioned above, the best way to do this is to use DFS Namespaces. The DFS service lets you create a UNC, which is in the form of \\domainname\ share instead of \\servername\share. The advantage is that with a DFS Namespace, there should be no reason why the share name should ever change because Namespaces are stored within Active Directory and are linked to target shares hosted on servers throughout your infrastructure. This lets you modify the share targets to your heart's content without ever affecting users or installations. That's because the DFS Namespace can point to multiple targets that can be in different locations. In addition, DFS Replication (DFSR) can replicate data from target to target to make sure the contents of all targets are identical.

Although the first version of DFS relied on the File Replication Service (FRS) which only replicated entire objects — copying a whole file even if only 1 byte has changed — DFSR supports delta compression replications, replicating only changes to existing files. This makes the DFSR engine even more powerful and useful for this scenario.

The second prong of this approach is to make sure that the source lists you include inside your packages include all possible locations for a package. For example, DFS Namespaces are wonderful for any system that is connected to the network, but what happens when the package is on a portable that is no longer connected to the network? Once again, users would be prompted to specify a location for source files, and this situation would even be worse since there would be no way a user could fix this problem short of having the installation CD with them. One way to solve this issue is to create a hidden partition on the hard drive of portable systems and copy all packages to this location prior to their installation. That way the location is available in the event of a problem with a product while the user is traveling.

Of course, this means that you need to maintain these special locations, but that is part of your software deployment infrastructure design and operation. Also, the vastly expanding default disk size on portables makes an approach such as this quite viable today.

NOTE

If you have already deployed packages and you have not managed source lists properly, you have probably run into some issues with these installations. There are several ways to repair source lists in deployed products. One is by using features that are potentially provided with your deployment tool. For example, if you are using Microsoft Systems Center Configuration Manager 2007 (SCCM), you can modify source lists after the fact for per machine product deployments. It is also possible to use scripts to modify source lists. Finally, you can simply redeploy a properly managed package. This also gives you the opportunity to rectify other potential problems you may have introduced before you standardized your application installation approaches (such as per user installs instead of per machine installs).

For more on managing source lists, see the Product Source Update Manager Whitepaper from Microsoft at www.microsoft.com/downloads/details.aspx?FamilyID=32F40DB4-6706-4E62-B867-AA1D332B6403&displaylang=en

3. Changes to Windows Installer 4.0

Windows Installer received a significant facelift to run with Windows Vista. Vista heralds a whole series of changes and modifications in terms of both user access and system protection. These changes affect application installations. Because of this, the most significant changes in WIS 4.0 are related to the following:

  • Compatibility with Restart Manager

  • Compatibility with User Account Control

  • Compatibility with User Account Control Patching

  • Support for Windows Resource Protection

Most existing MSI packages will run on Windows Vista, but it is always best to update your own packages to run with this version of WIS to make sure you have the latest built-in capabilities and compatibility.

Compatibility with Restart Manager

In order to avoid user disruptions as much as possible, Vista includes a new feature, the Restart Manager. By default, Vista relies on Restart Manager to stop and restart applications rather than stopping and restarting the system. It actually saves the state of applications and temporarily closes them to prevent the need to restart. The system is restored after the installation is complete without a restart.

Applications that are compatible with WIS 4.0 will include a new MsiRMFilesInUse dialog that will automatically link them with the Restart Manager's capabilities. For applications to run properly with Restart Manager once installed, they must include the new RegisterApplicationRestart function. Both can be added as a transform to packages that are not designed for WIS 4.0.

NOTE

More information on Windows Installer 4.0 and Restart Manager can be found at http://msdn2.microsoft.com/en-us/library/Aa372466.

Compatibility with User Account Control

User Account Control (UAC) is a new security feature of Windows Vista that is designed to let all users run with standard user privileges, even if you are logged in with an administrative account. Each time an action requires administrative privileges, UAC requests authorization from the user. The difference lies in how it does this. When logged in as an administrator, UAC simply requests you to allow or deny an action. When logged in as a standard user, UAC requests the name of an account with administrative privileges and its password to proceed.

Because of its integration with UAC, administrators can rely on WIS 4.0 to install all applications as managed applications. Managed applications are automatically installed with elevated privileges and are stored in the HKEY_LOCAL_MACHINE registry hive, which is the same as using the ALLUSERS=1 property. After an application is registered as a managed application, it will no longer prompt users or administrators during installation.

If applications are not registered as managed, then standard users will require over-the-shoulder credential assignment or asking someone else to fill in the user name and password for the installation to complete.

NOTE

More information on WIS 4.0 and UAC can be found at http://msdn2.microsoft.com/en-us/library/Aa372468.

Compatibility with User Account Control patching

Vista's UAC supports the ability to patch applications without requiring elevated privileges, but to do so, applications must be digitally signed. Several other conditions are required:

  • The application must have been installed by WIS 3.0 or higher.

  • If the application was installed on Windows XP, it must have been done with removable media — CD or DVD — otherwise it will not work. Note that this restriction does not apply to applications installed on Vista.

  • The application must have been installed for all users or per machine.

  • The patch or the original package must include the MsiPatchCertificate table, which in turn includes the digital certificate for the patch.

More conditions must be met, but when patches are properly prepared for Vista, they will install under standard user privileges. This is something you should always aim for in your patches.

NOTE

More information on patching with UAC can be found at http://msdn2.microsoft.com/en-us/library/Aa372388.

Support for Windows Resource Protection

Microsoft has renamed Windows System File Protection to Windows Resource Protection (WRP) in Windows Vista. WIS 4.0 may later integrate with WRP in the following manner:

  • If system files are contained within a package, WIS skips its installation and logs an entry into the log file and continues the installation. This is different from Windows 2000 and XP as WIS would call on SFP to install the file for it.

  • WRP protects both files and registry keys. As with files, if WIS encounters a protected registry key in the installation, it skips it, logs a warning in the log file, and moves on.

There is more to the integration, but for administrators preparing software packages, it is important to know that WRP does not allow WIS to update any protected resource.

NOTE

More information on WIS and WRP can be found at http://msdn2.microsoft.com/en-us/library/Aa372868.

NOTE

Any internally created packages should include a digital signature in order to support User Account Control (UAC) patching. UAC patching enables the authors of Windows Installer installations to identify digitally signed patches that can be applied and removed in the future by non-administrator users. This functionality is available beginning with Windows Installer version 3.0. User Account Control (UAC) patching was called least-privilege user account (LUA) patching in Windows XP. LUA patching is not available on Windows 2000 and Windows Server 2003.

4. Changes to Windows Installer 4.5

Windows Installer is available as a redistributable for Windows Vista SP1, Windows Server 2008, Windows XP SP2, and Windows Server 2003 SP1. It offers some new functions and features including two worth mentioning specifically:

  • Transaction support: As of this release, Windows Installer can now perform multiple-package installations using transaction processing.

  • Custom user interface support: A custom user interface can now be embedded within a Windows Installer package.

It is a good idea to deploy Windows Installer 4.5 as part of your Windows Vista corporate image. Because it is not included, you will need to download and install it manually.

Other -----------------
- Working with Windows Installer : Introducing Windows Installer
- Managing Windows Vista : Managing Settings for a Presentation
- Managing Windows Vista : Controlling the Power Options
- Add an Xbox 360 : Configure the Windows Vista–Based PC
- File Type Associations (part 4)
- File Type Associations (part 3) - Customize Context Menus for Files
- File Type Associations (part 2) - Change the Icon for All Files of a Type
- File Type Associations (part 1) - Anatomy of a File Type
- Registry Tasks and Tools (part 5) - Back Up the Registry
- Registry Tasks and Tools (part 4) - Export and Import Data with Registry Patches & Prevent Changes to a Registry Key
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
Celebrity Style, Fashion Trends, Beauty and Makeup Tips.
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server