Bug 817180 - PRD35 - [RFE] sysprep needs ability to specify Active Directory OU for VMs to join
Summary: PRD35 - [RFE] sysprep needs ability to specify Active Directory OU for VMs to...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.0.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.5.0
Assignee: Shahar Havivi
QA Contact: Pavel Novotny
URL:
Whiteboard: virt
Depends On:
Blocks: 1120948 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2012-04-27 22:41 UTC by Bryan Yount
Modified: 2019-03-22 07:03 UTC (History)
11 users (show)

Fixed In Version: vt2.2
Doc Type: Enhancement
Doc Text:
With this release, MachineObjectOU is now available for configuration for virtual machines that are using Sysprep. This allows users to specify an Active Directory OU for virtual machines to join.
Clone Of:
Environment:
Last Closed: 2015-02-11 17:50:00 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC
oVirt gerrit 26086 0 None MERGED core: Sysprep - Add user specify Active Directory OU 2020-04-30 16:17:26 UTC
oVirt gerrit 30143 0 None MERGED engine: sysprep MachineObjectOU fix closing xml tag 2020-04-30 16:17:26 UTC
oVirt gerrit 30144 0 None MERGED engine: sysprep MachineObjectOU fix closing xml tag 2020-04-30 16:17:26 UTC

Comment 3 Itamar Heim 2012-04-28 17:51:39 UTC
1. (I know not liked, but if pressing) hooks can probably handle this today by altering the floppy content on first run if getting this parameter from custom property.

2. in 3.1, this may be feasible via custom vm pay load - need to check, and not sure this will be via UI or only API.

[3. add this field in the product]

Comment 5 Bryan Yount 2012-04-30 21:08:24 UTC
(In reply to comment #3)
> 1. (I know not liked, but if pressing) hooks can probably handle this today by
> altering the floppy content on first run if getting this parameter from custom
> property.
> 
> 2. in 3.1, this may be feasible via custom vm pay load - need to check, and not
> sure this will be via UI or only API.
> 
> [3. add this field in the product]

It is somewhat pressing, yes. I know we don't write hooks for customers but is there anything I can provide to them that will assist us in developing this hook?


(In reply to comment #4)
> What prevents the customer from modifying the sysprep template file RHEVM
> provides?

We could do that but that assumes that the user will want every VM in the same OU. Sure, most of State Street's VMs likely will exist in a single OU but they want the functionality to specify the OU in the AdminPortal.

Comment 10 Michal Skrivanek 2012-09-26 12:51:37 UTC
to solve as a part of the redesign of sysprep to allow to supply a custom config file

Comment 11 Itamar Heim 2012-09-28 07:10:42 UTC
question is if important enough to be a named field (like timezone is), or just part of the custom config generic one

Comment 14 Shahar Havivi 2014-02-18 14:39:40 UTC
IIUC this is the required field that will be in the Add/Edit/RunOnce VM Sysprep section:
MachineObjectOU

user will need to add something like:
"OU=Desktops,OU=Machines,DC=Domain,DC=local"

Is that sufficient?

Comment 15 Scott Herold 2014-02-21 14:14:06 UTC
That is the correct syntax and sysprep.xml key.  The user will need to define the OU in the proper DN sytax as highlighted in Comment 14.

Comment 16 Shahar Havivi 2014-03-24 14:59:52 UTC
Scott, 
Do you have a suggestion for UI label for this field?

Comment 17 Shahar Havivi 2014-03-30 09:39:21 UTC
Does "Active Directory OU" sufficient enough?

Comment 18 Scott Herold 2014-04-01 11:20:41 UTC
Is it possible to have the label shown as "Active Directory OU", then have the ? tool tip with the definition "This field will map to MachineObjectOU within Sysprep"

Comment 19 Shahar Havivi 2014-04-01 14:03:30 UTC
(In reply to Scott Herold from comment #18)
> Is it possible to have the label shown as "Active Directory OU", then have
> the ? tool tip with the definition "This field will map to MachineObjectOU
> within Sysprep"

Sure, added to the patch

Comment 20 Pavel Novotny 2014-07-15 15:49:30 UTC
Clear FailedQA in ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch (beta).

Due to XML parse errors in all XML-based sysprep templates, caused by missing ending tag, i.e., `<MachineObjectOU>$MachineObjectOU$<MachineObjectOU>`.

Windows then complains about invalid answer file during the sysprep process.

Comment 22 Pavel Novotny 2014-09-12 16:19:40 UTC
Verified in rhevm-3.5.0-0.11.beta.el6ev.noarch (vt3).

If given, Active Directory Organizational Unit value is passed to sysprep file as MachineObjectOU parameter and Windows guest is then joined to it.

Comment 23 Yaniv Lavi 2015-01-19 15:06:22 UTC
Original problem was:

3. What is the nature and description of the request?
The sysprep answer file provided by RHEV-M needs the ability to specify an Active Directory OU for the VMs to join instead of the Windows default. This feature is supported by sysprep and I have it confirmed by a Microsoft representative.

4. Why does the customer need this? (List the business requirements here)
They have many OUs in their environment and would like the ability in the VM sysprep tab to specify which OU the VM will be placed in.

5. How would the customer like to achieve this? (List the functional
requirements here)
* The ability to specify an OU for a sysprep'd VM

6. For each functional requirement listed in question 5, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.
* option in VM properties
* new field in sysprep answer file

Comment 25 errata-xmlrpc 2015-02-11 17:50:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0158.html


Note You need to log in before you can comment on or make changes to this bug.