Вынос Data и notes.ini из Program Files

[LIGHT]

Господа, может кто советом поможет, опишу ситуевину.

Развернут у нас Domino и установлено порядка 400 клинетов, во время установки был выбран тип [только для меня] т.е. не мультиюзеровская установка. Затем, на предприятии развернули виндовый домен и служба которая за это отвечает категорически против открывать смертным досуп на запись в program files/lotus а без этого не мультиюзеровская версия не работает.

Выход нашелся "гениальный" бегать и переустанавлять клиентов 400! человекам в мултиюзеровким режиме, того клиент работает т.к. каталог данных колбасится в Documet Seting.

А вопрос в том, как бы так раскувыркнутся что бы ноги сидели в теплых тапочках.
Ребята кторые доменом рулят утверждают что MoveProfile в домене не помогает, что кстати странно. Может и в этом вопросе есть гуру.

Буду все очень спасибо.

 

[puks]

Думаю, что это только начало.
А ты предложи, тем, кто такой умный, автоматизировать этот процесс, так как простой перенос директории не изменит регистры. Работать, возможно, будет, если notes.ini будет корректно подправлен, но могут быть осложнения при апгрейдах и работе доп.приложений, которые ориентируются на записи в регистре, а не на ini файлы.

Единственный вариант, который я вижу, это создание автоматической процедуры средствами, которые используются при рассылке обновлений и тп. Никогда с этим не работал, только видел, что такое делали. Но твои умники, должны это знать. Сам я не люблю такую установку, так как ее сложнее администрить.

 

[PahanV]

ну если у вас виндовыи домен, то наверно каждыи пользователь имеет сетевои приватныи драив?!?!
и копировать полностью program files\lotus папку совсем не обязательно, будет достаточно папку DATA пользователя на сетевои приватныи драив перенести и поправить notes.ini ну и shortcut для запуска Lotus Notes Client конечно.

 

[LIGHT]

В любом случае это ножная работа и по сути не чем не отличается от мульти установки где директория data падает в documents текущего юзера, при этом еще и на сеть нагрузка не такая как с приватным LD

 

[collection]

Для: PahanV

папка data на сетевых дисках это зло !
Для: LIGHT
Автоматические процедуры средствами, которые используются при рассылке обновлений,SURunas к примеру, проведет инсталирование клиента поверх без правки ini файла. Насколько я понял проблема состоит в следующем нужно автоматически:
1) перенести диррексторию data пользователей за program files
2)изменить в notes.ini параматр указывающий расположение дирректории
В качестве решения:
1-использовать cmd сценарий привязанный к профилю пользователя домена сети, автоматически запускаемый при входе пользователя: типа copy что нужно куда нужно
2-Using a Desktop Policy to set notes.ini and Location parameters

Technote (FAQ)

Problem
The Desktop Policy contains a variety of settings that can be passed down to the user's system. If the available options do not include a desired parameter is there a way to add it to the Desktop policy?
Solution

Assigning notes.ini variables
You can use a Desktop Policy settings document to add or set notes.ini variables for Notes client users. This is an easy way to assign notes.ini variables to all Notes client users, or to a specific subset of Notes client users, at one time.

To use a policy to assign a notes.ini value to Notes client users, use the Domino Designer to add a new field to the Desktop Policy settings document. The new field must be named $PrefVariableName, where VariableName is the name of the notes.ini variable you want to set. In the new field on the Desktop Policy settings document, enter the value you want assigned to that notes.ini variable. That is the value that is set in the notes.ini for the assigned Notes users.

For example, assume that you want to use a policy settings document to add a font size setting of 5 to your notes.ini file. To change the font setting, do the following:

1. From the Domino Designer, open the Desktop Policy settings document form.
2. Create a new field named $PrefDisplay_font_adjustment.
3. Assign a value of 5 to the field $PrefDisplay_font_adjustment.
4. Save and exit.



Assigning Location document settings
You can use Desktop Policy settings documents to set field value in users' current Location documents.

This can be done by adding a new field to the policy settings document using the Domino Designer. The new field must be named LocAllVariableName, where VariableName is the name of the field you are setting in the Location documents.

In the new field on the Policy settings document, enter the value you want assigned to that Location document field. This new value is set on the assigned users' clients the next time they authenticate with their home server.

Notes

* Some settings require that the Notes client be restarted in order for the settings to take affect.
* For more information about adding the new field to Desktop Policy settings document, see the Domino Designer documentation.

This method will impact users' present Location documents only (the Location document being used to access the server), and will not cycle through all of the users' Location documents. If modifying multiple Location documents is required, a LotusScript agent must be created to perform the task.


Example
Detailed steps on how to create a custom Desktop Policy to change a Location document setting.

This example will copy a field from the Location document to a Policy Settings document. When you assign a Policy to the user with this setting it will change the time zone setting on their Location document.

To test this, first set the following field on the test user's Location document on their client machine to No:

Use operating system's time zone setting -> No

1. Using the Domino Designer client, open any Personal Address Book. Select File -> Database -> Open. Set the following:
Server: Local
Database: user name's Address Book
Filename: names.nsf

2. Click Open. Once in the design, expand the "Forms" folder on the left and double-click the "Location" form to put it in edit mode. The "Location" document should display in the big area on the right.

3. Open the "Advanced" tab, and copy the first line (text and radio button). Copy this line:

"Use operating system's time zone settings: UseOSTz"

4. Next, open the Domino directory in the Domino Designer client. Select File -> Database -> Open. Set the following:
Server: servername (this should be the Registration / Administration server of the domain:
Database: domain's Address Book
Filename: names.nsf

5. Once in the design, expand the "Forms" folder on the left and double-click the "Policy setting / Desktop Setting" form to put it in edit mode. The "Desktop Setting" document should display in the big area on the right.

6. Open the "Basics" tab.

7. Add a row in the "Basics" tab after the row with "Description". Select the row "Description" and select Table -> Append row.

8. Select the new row and paste. Answer "Yes" at the prompt. This will paste the text and radio button into the row.

9. Right-click the "UseOSTz" field. Change the field properties name to "LocAllUseOSTz" and at the bottom of the page change the default value to "1". Include the double quotes.

10, Save and close the "Deskop settings" document.

11. Create a new Desktop Settings document. You should see the "Use operating system's time zone settings:" field set to Yes.

12. Create a new Explicit Desktop Policy and select the Desktop Settings document.

13. Assign the policy to the user.

14. Replicate the Domino directory to the user's mail server - "replicate mail-servername names.nsf."

15. Have the user open their personal Address Book and select Action -> Remove Address Book Preferences. The user should delete all of their current Policies. To see the policies, hold down the Ctrl key and the Shift key, then select View -> Go To from the menu. This key combination displays the hidden views. Select the ($Policies) folder.

16. Close down all of the Notes and Designer clients and restart the client machine.

17. Check the user's Location document -> Advanced tab. To open the current Location document, select the Location document area of the status bar (bottom right) and choose "Edit Current." The settings should be "Yes."

Supporting information
The information in this technote can also be found in the Notes Domino 6.5.4 Release Notes and in the Domino Administrator 7.x Help file (Contents -> User and Server Configuration -> Policies -> Using Policies to assign Notes.ini or Location document settings to Notes client users). Note: The Notes Domino 6.5.4 Release Notes incorrectly indicates that the LocAll variables should have a $ prefix.

PS Находясь в отпуске все кажется так просто...

 

[Gray]

Для: LIGHT
Честно говоря, твоя ситуация весьма распространенная. Т.е. закручивание гаек безопасниками - весьма частый способ для них самоутвердиться.
Способ, описанный в факе, любезно предоставленном collection мог бы и помочь, если бы не одно НО!. Виндовый Домен уже развернут и разрешения на запись в notes.ini уже нет.
Предполагаю, что и радмины и прочие ремотные десктопы тоже уже убиты, как класс.

Я вижу у тебя только один выход. И он никак не связан с админством. Пишешь пояснительную записку руководству и требуешь включить в политики исключение - разрешение на запись в program files\lotus\data.
Поверь, твои проблемы намного быстрее решатся, если о них будет знать тот, кто выше, чем безопасники.
Ну а дальше - как поступить - деплоить мултиюзерного клиента или скриптом перенести всю папку - решать тебе. Но как по мне - проги в корне - зло.

 

[LIGHT]

Сдел финт ушами!
На CBuilder написал маленькую программулинку, которая выдергивает папку data в Documents выранного юзера (типа ListBox всех Documents and settings/$USERS) дальше тыкаю на кнопку и понеслось, директория копируется в папку юзера, правится notes.ini и правится ключи реестра.
Все работает, осталось 2 вопроса решить.
1. Это notes ini тоже переместитить в папку юзера и в реестре поправить к нему путь, но это дело последнее.
2. Самый гимор сейчас выскачил с тем, что лотуc где-то запоминает откуда был открыт последний ID пользователя, чаще Program/Lotus/Notes/Data а т.к. data переезжает, то при запуске клиент приходится наводить ручками на id-шник. Т.е. участие админа нужно, вот если бы узнать где это прописано, то вообще программулинка бы рулила! Может кто знает, я нифига не нашел.

Все нешел, в notes ini 2 переменных 1 это ID вторая это где его искать.

 

[Stas A]

2. Самый гимор сейчас выскачил с тем, что лотуc где-то запоминает откуда был открыт последний ID пользователя, чаще Program/Lotus/Notes/Data а т.к. data переезжает, то при запуске клиент приходится наводить ручками на id-шник. Т.е. участие админа нужно, вот если бы узнать где это прописано, то вообще программулинка бы рулила! Может кто знает, я нифига не нашел.

а еще он в базе клиента names.nsf прописывается если настроено несколько мест вызова...

 

[LIGHT]

<!--QuoteBegin-Stas A+22:08:2007, 12:53 -->
<span class="vbquote">(Stas A @ 22:08:2007, 12:53 )</span><!--QuoteEBegin-->а еще он в базе клиента names.nsf прописывается если настроено несколько мест вызова...

[snapback]76028" rel="nofollow" target="_blank[/snapback]​

[/quote]
Что-то не видел такого, ну в принципе у нас 1 место...
Все вроде получилось, только ни фига не понял, лотус колбасит кучу ключей в реестр в том числе есть ключ для место положения notes.ini, короче к чему это я. Взял бубен по сильнее, поизвращался с ключами, и не один кроме пути к notes.ini роли не играет, взял вообще ветку снес. Один фиг все работает в общем, дальше шаманю.

<!--QuoteBegin-collection+20:08:2007, 12:38 -->
<span class="vbquote">(collection @ 20:08:2007, 12:38 )</span><!--QuoteEBegin-->Для: LIGHT
Автоматические процедуры средствами, которые используются при рассылке обновлений,SURunas к примеру, проведет инсталирование клиента поверх без правки ini файла. Насколько я понял проблема состоит в следующем нужно автоматически:
1) перенести диррексторию data пользователей за program files
2)изменить в notes.ini параматр указывающий расположение дирректории
В качестве решения:
1-использовать cmd сценарий привязанный к профилю пользователя домена сети, автоматически запускаемый при входе пользователя: типа copy что нужно куда нужно
2-Using a Desktop Policy to set notes.ini and Location parameters
Цитата

Technote (FAQ)

..............
.................
...................


PS Находясь в отпуске все кажется так просто... biggrin.gif

[snapback]75742" rel="nofollow" target="_blank[/snapback]​

[/quote]

Вау! Респект, очень интересный фак.

 

[puks]

<!--QuoteBegin-Stas A+22:08:2007, 04:53 -->
<span class="vbquote">(Stas A @ 22:08:2007, 04:53 )</span><!--QuoteEBegin-->а еще он в базе клиента names.nsf прописывается если настроено несколько мест вызова...

[snapback]76028" rel="nofollow" target="_blank[/snapback]​

[/quote]

Не несколько мест, а если в location есть привязка к id и он не находится в лотусовой директории.

<!--QuoteBegin-LIGHT+22:08:2007, 06:58 -->
<span class="vbquote">(LIGHT @ 22:08:2007, 06:58 )</span><!--QuoteEBegin-->в том числе есть ключ для место положения notes.ini

[snapback]76051" rel="nofollow" target="_blank[/snapback]​

[/quote]

Но ведь в командной стоке есть параметр, который указвает notes.ini . Типа C:\Notes\notes.exe "=C:\Notes\notes.ini"

 

[Stas A]

Я бы сделал иначе, перенес lotus(к слову всегда так его ставил еще с версии 4)в св корень диска), в notes.ini поменять пару параметров нахождения data и самого lotus, доменной политике разрешить запись в эту папку, проверить что бы у клиентов не было notes.ini в windows(будет использоваться именно он).
В names может быть настройка на нескольких пользователей(места вызова или locations), в каждой из которой может быть прописан путь к id файлу...

а самый идеальный вариант - использовать сетевой lotus(правда для мощного файл сервера), папка lotus на сервере(к примеру z диск/lotus), data и ini файл находятся в личной папке пользователя(z диск/userName), такая структура позволит без лишней синхронизации переносить пользователей с компа на комп.
В продолжении my documents храняться на сервере и т.д.
-супер реализация, участвовал в ее интергрировании.

 

[puks]

Для: Stas A
<!--QuoteBegin-Stas A+23:08:2007, 05:52 -->
<span class="vbquote">(Stas A @ 23:08:2007, 05:52 )</span><!--QuoteEBegin-->использовать сетевой lotus

[snapback]76148" rel="nofollow" target="_blank[/snapback]​

[/quote]

Очень чувствительна к работе сети. Не рекомендуется и не поддерживается IBM.

 

[LIGHT]

<!--QuoteBegin-Stas A+23:08:2007, 13:52 -->
<span class="vbquote">(Stas A @ 23:08:2007, 13:52 )</span><!--QuoteEBegin-->Я бы сделал иначе, перенес lotus(к слову всегда так его ставил еще с версии 4)в сsad.gifв корень диска), в notes.ini поменять пару параметров нахождения data и самого lotus, доменной политике разрешить запись в эту папку, проверить что бы у клиентов не было notes.ini в windows(будет использоваться именно он).
В names может быть настройка на нескольких пользователей(места вызова или locations), в каждой из которой может быть прописан путь к id файлу...

а самый идеальный вариант - использовать сетевой lotus(правда для мощного файл сервера), папка lotus на сервере(к примеру z диск/lotus), data и ini файл находятся в личной папке пользователя(z диск/userName), такая структура позволит без лишней синхронизации переносить пользователей с компа на комп.
В продолжении my documents храняться на сервере и т.д.
-супер реализация, участвовал в ее интергрировании.

[snapback]76148" rel="nofollow" target="_blank[/snapback]​

[/quote]
Чувтвую гимороя вы тут написали:
ЗАЧЕМ! огород городить, не достаточно ли в вашем случае просто прописать политику на prog.files/lotus/notes/ ??? то на то и выйдет, а вы видать какой-то бубен имортный используете


<!--QuoteBegin-puks+23:08:2007, 14:17 -->
<span class="vbquote">(puks @ 23:08:2007, 14:17 )</span><!--QuoteEBegin-->Очень чувствительна к работе сети. Не рекомендуется и не поддерживается IBM.

[snapback]76155" rel="nofollow" target="_blank[/snapback]​

[/quote]
Верно! Есть правда одна интересная статей на эту тему в Системном Администраторе, правда там про NIX домен, но так для образования. Кому интересно цепряю к посту скан.

 

[puks]

Для: LIGHT
Год назад я придумал подобную систему для конторы, которая хранила персональные файлы на сетевом диске. Роуминг им не подходил. Правда, до испытаний дело не дошло из-за природной лени менеджмента. В моей схеме я использовал не файловое копирование, а репликационный механизм, так как все важные файлы, кроме ini и id можно реплицировать.

 

[Cosmogen]

Для: LIGHT
Год назад я придумал подобную систему для конторы, которая хранила персональные файлы на сетевом диске. Роуминг им не подходил. Правда, до испытаний дело не дошло из-за природной лени менеджмента. В моей схеме я использовал не файловое копирование, а репликационный механизм, так как все важные файлы, кроме ini и id можно реплицировать.

Доброго времени суток!
Очень даже хорошо работает, все .id файлы на сетевом сервере, если потребителю надо "переехать" с одного компьютера на другой-нет проблем .id файл везде доступен. До сих пор никаких проблем нет.

 

[puks]

<!--QuoteBegin-Cosmogen+31:08:2007, 10:14 -->
<span class="vbquote">(Cosmogen @ 31:08:2007, 10:14 )</span><!--QuoteEBegin-->Очень даже хорошо работает, все .id файлы на сетевом сервере, если потребителю надо "переехать" с одного компьютера на другой-нет проблем .id файл везде доступен. До сих пор никаких проблем нет.

[snapback]76983" rel="nofollow" target="_blank[/snapback]​

[/quote]
Переезд - это не один id файл. Все сетевые конфигурации работают хорошо, пока сеть хорошо работает. Как только возникают проблемы с сетью, то ... Короче, сам увидишь.

 

[Cosmogen]

<!--QuoteBegin-puks+31:08:2007, 16:53 -->
<span class="vbquote">(puks @ 31:08:2007, 16:53 )</span><!--QuoteEBegin-->Переезд - это не один id файл. Все сетевые конфигурации работают хорошо, пока сеть хорошо работает. Как только возникают проблемы с сетью, то ... Короче, сам увидишь.

[snapback]76985" rel="nofollow" target="_blank[/snapback]​

[/quote]
Ну так если проблемы с сетью, то тогда не только проблемы с .id файлами будут, но и с доступом к Домино h34r:
5 лет на таком принцепе работаем и никаких проблем.
Естественно что иногда у потребителя есть локальный ПЯ где он себе хранит нужные ему мейлы и при "переезде" надо будет его скопировать. Но для более грамотных потребителей идея размещения .id файлов на сетевом сервере очень даже полезна, экономит очень много времени : Потребитель сам себе достает свой .id и работает. Речь идет о 2000 человек, не будете же вы каждому переносить .id файл на новый компьютер.
Но это все конечно не относится к теме переноса лотус клиента с program files\lotus\notes....

 

[puks]

<!--QuoteBegin-Cosmogen+3:09:2007, 02:07 -->
<span class="vbquote">(Cosmogen @ 3:09:2007, 02:07 )</span><!--QuoteEBegin-->Ну так если проблемы с сетью, то тогда не только проблемы с .id файлами будут, но и с доступом к Домино

[snapback]77067" rel="nofollow" target="_blank[/snapback]​

[/quote]
Я не совсем корректно выразился. Файлы обычно хранятся на файловом сервере, а лотусовый сервер - это отдельная машина. Соответственно, проблемы с сетью в моем топике - это проблемы доступа к файловому серверу.

<!--QuoteBegin-Cosmogen+3:09:2007, 02:07 -->
<span class="vbquote">(Cosmogen @ 3:09:2007, 02:07 )</span><!--QuoteEBegin-->Но для более грамотных потребителей идея размещения .id файлов на сетевом сервере очень даже полезна, экономит очень много времени

[snapback]77067" rel="nofollow" target="_blank[/snapback]​

[/quote]

У вас 2000 грамотных потребителей? И они все ходят с места на место? Не совсем понимаю, что экономит id на файловом сервере. Ведь workspace не переносится, адресная книга - тоже. У тебя все id в куче навалены или у каждого в его домашней директории? Если в личной директории, то он и залогиниться должен под своим именем на этом компе и права иметь на нем соответствующие, что не увеличивает общую секьюрити.

Это уже споры на религиозные темы. Если у тебя работает и все довольны, то и хорошо.