 |
|
|
 |
Enterprise Deployment of DIG Security Settings
In order to run the DIG Client through a web browser, the machine on which the Client will run needs to be configured properly. This process has been documented and communicated in a number of ways since the 2.0 release. This month, we bring you another option for configuring your DIG Client machines.
This article discusses simplifying large-scale deployments of the DIG "No-Touch" Client using Group Policies in Active Directory.
The Microsoft .NET Framework uses a series of Code Groups and Permission sets to determine what .NET programs are safe to run and what these programs are allowed to do while they are running.
Before your users can run the DIG Client from a web browser, the computer on which the Client will run has to be set up with a Code Group that grants the appropriate permissions so that the machine knows that the code coming down from the server is safe to run. Rather than manually setting these Code Groups on each individual computer, the Windows domain administrator can set up a Group Policy, deployed through an MSI package, that will configure every computer that you want the DIG "No-Touch" Client to be run from.
The process for deploying .NET Group Policies includes:
- Creating the Code Groups
- Creating the MSI Package
- Applying the Package
- Testing the Organizational Unit
Creating the Code Groups
Before creating the Group Policy you want to distribute, you must create the Code Groups that will be included. All Code Groups defined on the machine where the MSI Package is created will be included in the Package. Therefore, it is best to start from a clean Code Group configuration.
If you have access to a machine with a fresh .NET Framework installation, use that machine. Otherwise, you must remove Code Groups that you do not want to distribute from the machine that you choose to use.
- From the Windows Control Panel, choose Administrative Tools, and then choose .NET Framework Configuration.
- Expand Runtime Security Policy / Machine / Code Groups / All Code.
If the machine contains Code Groups that you do not want to distribute, remove them.
You can:
- Right-click an individual Code Group and choose the Delete command to
remove individual Code Groups.
- Right-click the Machine control and choose the Reset command to restore
the initial .NET Framework settings.
- Create the Code Group(s) you want to distribute.
Complete instructions for configuring the DIG Client Code Group can be found in your DIG documentation.
Following are the general settings required:
- New Group Name: DIG_NET
- Condition Type: URL
- URL: URL of the DIG Server, followed by /* (e.g., http://dig.visualanalytics.com/*)
- Permission Set: FullTrust
Creating the MSI Package
Once you have set your Code Groups to reflect exactly what you want to distribute, you can create the MSI Package.
- In the .NET Configuration control, click the Runtime Security Policy control.
- In the Tasks list on the right, click Create Deployment Package.
- In the Deployment Package Wizard, click the Machine option.
- Click the Browse button.
- Navigate to the directory where you want to store the package file and give it a name.
Tip: If you can access the directory from which it will be deployed, save it there. Otherwise, you will need to copy the saved file to the appropriate location for deployment.
- Click the Save button.
- Click the Next button.
- Click the Finish button to create the MSI file.
Applying the Package
In order to deploy the MSI Package to the computers in your Organizational Unit, you must add it to the list of software that is installed onto these computers when they connect to the domain.
However, before you do this you must set the properties for this list so that any new packages will be forced onto the machines regardless of whether or not the machines think that the overall group policy has changed or not.
To do this, you must turn on the "Process even if the Group Policy objects have not changed" option of the "Software Installation Policy processing" sub policy, which is found under the "Computer Configuration\Administrative Templates\System\Group Policy" subgroup for each organization unit.
Our experience has shown that packages created by the .NET Framework are not advertised to the client machines as a change to the overall group policy. This causes a conflict with the deployment of the package where the machines did not appear to notice the change. Setting this option eliminates this issue because it forces the client machines to pay attention to all changes regarding the list of software deployed via the Group Policy.
More information on this option can be found at
http://msdn.microsoft.com/library/default.asp?url=
/library/en-us/gp/42.asp.
Once you have adjusted the properties for the software list, you can add the MSI Package to your organizational unit's list of software.
- Open the Group Policy MMC snap-in.
- Use the Computer Configuration / Software Settings / Software Installation option to add the MSI Package.
- Your next step depends on your operating system:
If you are working on a Windows 2000 machine, your set up is complete and you can close the Group Policy MMC. See the procedure below to test the Organizational Unit.
If you are working on a Windows XP machine, continue with step 4 below.
- Once you have added (installed) the package, open the package properties dialog and choose the Assigned option.
Even if the Assigned option is already selected, you must select it again.
- In the Deployment options area, select the Install this application at logon option.
- Click the OK button.
- Close the Group Policy MMC and continue with "Testing the Organizational Unit," below.
Testing the Organizational Unit
Once you have created and deployed your MSI Package, you can test it by simply rebooting one machine in your organizational unit.
When the machine starts, a message will display, prior to the logon prompt, indicating that the package is being installed. This message should display only the first time the machine logs in. After the initial install, the settings will be silently applied every time the client machine is booted.
For additional information, reference the MSDN at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/entsecpoladmin.asp
|
|
|
 |
 |
...that you can use wild card characters when searching text-based sources?
When searching text-based sources, including documents, web sites, e-mail archives and other files, you can use wild card characters to create advanced search strings.
By default, DIG uses your database search criteria to populate the File, Web and E-mail Search Options field. You can manually edit this string for text-based searching. Additionally, you can enter a search string directly into this field and bypass database searching altogether.
When defining your text-based search string, you can use the wild cards described below to narrow or broaden your search.
|
| Wild Card |
Does |
Example |
| ? |
Matches any single character |
r?d
finds values such as red, rid and rod |
| * |
Matches any number of characters |
r*d
finds values such as round, read, road, red, rid and rod |
| % |
Performs a Fuzzy Search on a word |
arrest AND %crime
finds any document containing arrest AND
variants of crime such as crome and crims |
| # |
Performs a Phonic Search on a word |
#smith AND #chris
finds any document containing variants of smith such as smyth, smith, smythe AND
variants of chris such as kris |
| ~ |
Performs Stemming on a word |
indicted AND ~fire
finds any document containing indicted AND
variants of fire such as firearms |
| & |
Performs a Synonym Search on a word |
arrest AND &document
finds any document containing arrest AND
variants of document such as file, record and text |
| ~~ |
Specifies a numeric range |
18~~25
matches all values between 18 and 25 including 19, 20, 21, 22, 23 and 24 |
|
|
|
 |
|
