Support 1

[Support 1]

quote:

---

Here is the fix from one of the other IT persons here…

---

Do you mean that the problem has been resolved with this fix?

quote:

---

If I run the viewer and try a search directly off of the console of the windows 2003 server, it works just fine.

---

Can you confirm whether .NET 2.0 is installed on this server? Whether .NET 1.1 is also installed does not matter.

quote:

---

“Unless there is some reason for running Creator off the network drive, restore the trust level for it back to the default. This maximizes your security.”

Does this mean remove my Code groups, or uninstall and reinstall .Net 1.1. I have tried uninstalling and reinstalling .Net 1.1 but that still didn’t work. My code groups are set to Enterprise level only.

---

I am not sure what you mean by “code groups”. To change the “trust level” for Creator, I mean:

• From the Windows Control Panel, select Administrative Tools.
• Select Microsoft .NET Framework 1.1 Wizards.
• When the dialog .NET Wizards appears, click Trust an Assembly.
• On the page Trust an Assembly, select either “Make changes to this computer” or “Make changes for the current user only”, as appropriate. Click Next >.
• On the page Which Assembly Do You Want to Trust?, click Browse… and select the relevant application file located on the network. Click Open, then Next >.
• On the page Trust this assembly or all assemblies from this publisher?, select the option “This one assembly”. Click Next >.
• On the page Choose the Minimum Level of Trust for the Assembly, drag the slider to “None”. Click Next >, then Finish.

To my knowledge, in order to execute a .NET assembly from another computer, it is sufficient to use the Trust an Assembly Wizard. It is also preferable to using Adjust Zone Security, which applies the new security setting to all assemblies in the relevant zone.

I hope this is clearer now.

Regards,
Advansys Support

[This message was edited by Support 1 on October 21, 2007 at 07:03 PM.]

[Support 1]

This is correct: Archive To Go requires Local access in order to save the message envelope properties. Local access is typically used by individuals who wish to archive their own accounts. These individuals would need to know their own passwords of course, though it is possible for an account to have a blank password.

Enterprise access permits an administrator to archive one or more accounts without the need for a password. Unfortunately the GroupWise third party API does not provide a way to retrieve the mail envelope properties with Enterprise access.

Regards,
Advansys Support

[This message was edited by Support 1 on October 17, 2007 at 10:11 PM.]

[Support 1]

Thank you for your inquiry.

You wrote: “adds the link to the locations file.” Are you referring to the applet constant SHARED_LOCATIONS?

It should be possible to set up automatic resolution from a GroupWise folder to a specific location. This is true for personal folders as well as GroupWise system folders (Mailbox, Sent Items, etc). It sounds like your locations file has the correct settings for the system folders.

Each location has a field representing the associated GroupWise folder, if any. Your program will need to ensure this field is defined for every GroupWise folder that you want to support.

You may need to experiment with editing the locations file using Message Saver. To do so:

• Start Message Saver while holding <Ctrl> down; this will open the Configuration Settings dialog.
• On the Save Locations tab, select a location and click Edit… (or double-click the location); this will open the Folder Location Properties dialog.
• The field “GroupWise folder” has a browse button “…” to the far right. Click this button to select the source folder associated with the target location.
• Save your changes and close Message Saver.
• Open the locations file using a text editor to see how Message Saver has formatted the location.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Thank you for sending the updates.

You will not be able to set the .NET trust level for Archive To Go Viewer because it is a Win32 (not .NET) application.

Have you tried to use Finder/Indexer locally on the Windows 2003 Server machine?

You noted in your initial post that you have both .NET 1.1 and 2.0 installed. Any .NET application will, by default, execute on the highest available .NET runtime, ie. 2.0 in your case. This is configurable for each application, but there should be no need to force Archive To Go to use 1.1.

I suggest that you do the following:

• Unless there is some reason for running Creator off the network drive, restore the trust level for it back to the default. This maximizes your security.
• Using the Wizard for .NET 2.0 (instead of .NET 1.1) increase the trust level for running Finder (and Indexer if indexing/reindexing might be necessary) from a network drive.

I hope this helps.

Regards,
Advansys Support

[Support 1]

Thank you for your inquiry.

1) It is a known problem that the folder selection dialog ignores a UNC path. Unfortunately we have not yet found a solution for this, and until we do I hope it does not become a major issue for you.

2) Regarding the error:

“Application has generated an exception that could not be handled”

This is most likely to do with the default security policy in the .NET Framework, for code obtained from a remote location, eg. a network drive. Have you already followed the directions at the featured topic Running Archive To Go from a Network drive?

Regards,
Advansys Support

[Support 1]

Thank you for your inquiry.

Have you already followed the directions at the featured topic Running Archive To Go from a Network drive ?

quote:

---

…I also went into the .NET configuration and made Archive to Go a more trusted app.

---

For which Archive To Go module (ie. Creator, Finder, Indexer) did you increase the trust level? Generally it should only be necessary for Finder and Indexer.

Regards,
Advansys Support

[Support 1]

Thank you for your inquiry.

The information you refer to is not available to the general public. Please write to support@advansyscorp.com, indicating the name of your organization and your business requirement.

Regards,
Advansys Support

[Support 1]

Ralf,

Thanks for your reply.

Regards,
Advansys Support

[Support 1]

Sorry the delay.

I am not sure what has caused this error, but our engineers are looking into it.

You mentioned that you are accessing an archive that is on a network drive. Have you already followed the directions for Running Archive To Go from a Network drive?

Are you running the Finder from a non-admin account?

Are you running Finder locally on a Windows Server 2003 machine? If so, this problem should be fixed by adding your account to the Performance Counter user group.

Regards,
Advansys Support

[This message was edited by Support 1 on October 15, 2007 at 06:32 PM.]

[Support 1]

quote:

---

We are using groupwise 6.5 but the user always chooses “Forward” never “Forward as Attachment”.

---

In my previous post I mentioned “attached messages”. By this I meant messages that the user has received as attachments. So the problem is in opening a message attachment and invoking CommandMessage with that message active. Here’s the relevant item in the change log for GroupWise 7.0.3:

quote:

---

Calling the CommandMessage property works on an attached message.

---

Regards,
Advansys Support

[Support 1]

Are the users trying to forward attached messages? The CommandMessage property can only be expected to work reliably in GroupWise 7.0.3, which adds support for attached messages with CommandMessage.

In addition, here is an excerpt from the online documentation:

quote:

---

CommandMessage isn’t available for new messages. If you try to access Manager.ClientState.CommandMessage from a new message, GroupWise 6.5 throws an “Unspecified error” exception.

---

I hope this helps.

Regards,
Support

[Support 1]

I’m pleased about your result and thank you for the confirmation.

Regards,
Advansys Support

[Support 1]

When manually composing an HTML-format message, GroupWise translates the [Enter] key into the <BR> HTML tag. This suggests the following approach for both plain-text and HTML: does it work when you use this code?

  
  Call GroupWise.FocusSet(10, "")
  GroupWise.PosTextTop
  GroupWise.Enter
  GroupWise.TypeText(FullName)
  GroupWise.Enter
  GroupWise.TypeText(Title)
  GroupWise.Enter
  GroupWise.TypeText(CompanyName)
  GroupWise.Enter
  GroupWise.TypeText(Street)
  GroupWise.Enter
  GroupWise.TypeText(City & ", " & State & " " & Zip)
  GroupWise.Enter
  GroupWise.TypeText("Phone: " & Phone)
  GroupWise.Enter
  GroupWise.TypeText("Fax: " & FaxNum)
  GroupWise.Enter
  GroupWise.TypeText("Email: " & LCase(Email))
  GroupWise.Enter
  GroupWise.TypeText("Website: " & Website)
  Groupwise.Enter
  GroupWise.PosTextTop

Regards,
Advansys Support

[Support 1]

Thank you for reporting this issue.

Could you send the process log from the export, to support@advansyscorp.com, please? The log is a file located in the export archive folder; if the archive folder is “jsmith Archive” it should contain the file “jsmith.log”.

Can you confirm that all sub-folders and files in the archive folder were copied to CD-ROM? Tools like WinMerge and FastLynx can simplify this task. Each CD-ROM should contain, below the folder named, eg. “media-01”, “media-02”:

_index [if an index was requested]
_metatata
_viewer
data

In addition, please zip the “_metadata” sub-folder and send it to the above address. This folder contains only:

• The folder names in a GroupWise account.
• For each exported message, its sender, recipients, subject, date.
• For each exported contact, its display name (if available), email address.

We look forward to your reply.

Regards,
Advansys Support

[Support 1]

Thank you for reporting this.

Actually it is a known issue that was introduced in the first Beta for version 1.5 – but it has been fixed in the current Beta.

Regards,
Advansys Support

[Author]

Replies