On 05/12/11 12:17, Joseph Cugini wrote:
> I am on week two of my Windchill e-learning exercises and product
> install/configuration/3.4 migration. As I see from the post of many folks on the
> exploder, the more you learn the more you question.
You can't imagine... You are just getting started. You need to be willing to
endure copious amounts of:
- Learning
- reading
- searching this Solutions list
- experimenting with an infinite number of combinations of Windchill properties,
java settings, Oracle settings, Vaulting combinations, Apache settings, Tomcat
settings, Life Cyles, Work Flows, Access Policies, Roles, Teams, Contexts,
Templates, and etc (much etc...)
- late nights
- Learning (Did I already mention that?)
> Previous threads seem cover
> most of the newbie questions. I am however curious what others think about the
> following.
>
> Thank you in advance for your replies.
>
> -Joe
>
> ·Our plan is to implement Intralink 9.1. Primarily because we can maintain our
> concurrent license model and so that we don’t have to pay for Oracle separately
> since it was originally bundled with Intralink 3.4. Is this the same for others
> implementing Intralink vs PDMLink?
Migrating from Ilink 3.4 to Intralink 9.1 or PDMLink 9.1 is about the same
amount of migration/configuration work. And the same amount of training needed
for your users. I think if you add up the migration/configuration and training
cost you will see that it far out weighs extra cost of Oracle (PDMLink) vs
Oracle (Intralink).
Plus you get a lot more functionality in PDMLink.
So why bother with Intralink? That was our reasoning for going to PDMLink.
>
> ·How many products/libraries did you implement? If we were to mirror our 3.4
> folder structure I’d have 5 products (representing our business areas) and 1
> library. Inside of each product there would be a folder structure that
> represented our individual programs. Our access control policies would be the
> same for all products and we do not restrict access of any of our engineers
> between programs. We’d utilize the same basic lifecycle for all context.
> Considering these facts I’m having a tough time understanding why I’d implement
> separate product context for every one of our programs (as PTC typically
> suggests). It just seems like that will lead to excess administration down the
> road.
We implemented a Context for each team as opposed to each product. There are
many viewpoints on this subject.
>
> ·At what context did you implement your access control policies? At the
> product/organization/site? From my limited understanding, each context inherits
> policies from its parent. It also appears that the policies are duplicated at
> each level when a new context is created. So, if I plan on having the same ACP’s
> for all contexts does it make sense to implement my changes at the organization
> level and delete the ones from the individual context?
I went with the "remove access policies from Product/Library context and put
them at the Organization level" philosophy. Much easier to maintain.
What you want to do is create a Product template and a Library template that
have these access policies removed (along with all the other settings you
want for the default). Then use these templates for creation of new products
and libraries.
--
------------------------------------------------------------------------
Randy Jones
Systems Administrator
Great Plains Mfg., Inc.
1525 E North St
PO Box 5060
Salina, KS USA 67401
email: -
Phone: 785-823-3276
Fax: 785-667-2695
------------------------------------------------------------------------
