Posts made by Carsten Jensen

@Joseph
I guess you didn’t read/understand the problem, but your answer has no relevance for the subject.

Unfortunately it’s not an option for me to connect the FOG server to the internet.
it’s not critical for me though it’s nice to see the vendor

Perhaps a file upload form for manually updating would be available in the future?

I’ve been trying to manually update the oui.txt, copying the file into
/var/www/fog/management/other

is the import triggered by a cron, or will it only import after pressing the update button which fails due to it cannot download the file.
the FOG server is not connected to the internet, so it cannot download the oui.txt thus I have to do it manually.

cheers

Please see the attached file for full details, but answers are also below.

• Yes, it’s using an unattended file for sysprep.
• And yes it skips the create PC name / User
• No, hostname is not defined*

That sounds about right. Really weird.
I’m going to start making a sysprep machine for Win7 with some slight changes, most should look like the Win81 sysprep though. This is merely to see if the same server acts weird there or if it’s a Win81 problem.

[url=“/_imported_xf_attachments/1/1370_unattended3-fog.xml.txt?:”]unattended3-fog.xml.txt[/url]

An update …
On Win7 computers that hasn’t been sysprepped, the renaming works.

There has been no time to test if Win81 works if it hasn’t been sysprepped.
Though I’ll see if I can find some time to make more tests.

After the problematic host was removed directly from the database, there has been no re-occurences of the problem.

As per suggestion, the initial group has been deleted, and all hosts could be added and deleted in the group using the GUI.

Something went wrong with the first hosts being added, but there is no indication what it was, and now it’s not reproducable.

as a side note. would it be possible to make the list of hosts window in Group management -> group -> membership
dynamic so one can resize the window. giving a better overview, and easier access to marking hosts for adding.

bump

No, UAC is not disabled, the user doesn’t have administrative permissions either.
But it should not be the case when a service with credentials executes the scripts.

But even a simple “copy these files to desktop” batch file doesn’t run.

For now things are done manually, as it seems the great devs, are in the progress, of making a new service client.

@jayphizzle: the master is called udd003, and of course all the other clients have a number ranging from udd001-udd024.

@junkhacker: The host computers are all alike, same motherboard etc. There are 2 netcards but one has been disabled in the BIOS.
This was done prior image creation. The master image was created on the computer. No VM’s involved.

Oh, and something to add, these computers are virgin computers

Sorry for triple posting in a row here… I can’t say if this is a bug so it’s up for a discussion here, posting here as it might have some relevance to the prior.

looking in the database table groupMembers I can see there is a row gmHostID, I can imagine that this row should refer to the ID in hosts (if it isn’t please disregard this post) the groupMembers.gmHostID doesn’t seem to match hosts.ID.

Strangly enough, the host that had problems in the group (mentioned above), did have the same number in both groupMembers.gmHostID and hosts.ID.

what it seems to be wrong is that there are fx hosts.ID 4,5,6 but there are no groupMembers.gmHostID 4,5,6, though there are some higher numbes in gmHostID which doesn’t exist in hosts.ID

except for the few first clients (3), which was added manually. The rest of the clients were added using the netboot to Full host registration

After deleting the host from FOG
and try to multicast to the rest of the group, I get an error message that the hosts doesn’t have unified image assignments,
which they do, and there were no problems scheduling a multicast prior to the host deletion.

Running FOG 1.2.0

EDIT:
In the regular groupview there are 21 hosts
but looking in groupview in tasks, there are 22 hosts

For some reason, I cannot delete a computer from a group.

I’ve tried from group view, and also from the host view.

There is the “updated” message but nothing happens.

The host in mention is the first member of the group

As I said before, I hear you, as in I understand what you’re saying, you won’t add this feature.

With a reference to the “the big picture” I’m refering to the subject/problem (it should probably have written “my big…” instead of “the…”) If it was understood differently or negatively I appologize that was not the intention, reading through the thread again it could look like it, but as I said, it wasn’t the intention.

Making core changes to an application is not something I’m willing to do any longer.
I’ve tried that, lost the documentation and can’t upgrade without having to restart the whole hack.

And I know what you’re going through, coding/support/documentation etc. to the OSS commnunity, it’s not a stranger to me.

just fyi:
[quote]
I can see others creating a tasking and not understanding why that one system isn’t being imaged with the rest when the expected action is of that type
[/quote]
A big red (pink?) warning appears on the screen when a client fails.

Andy

What you fail to realize is that diy-hacks into a product needs to be maintained for every single upgrade whether it’s a bug fix upgrade or a major feature upgrade.

What you also fail to see is that this is a bug report which can tilt in either direction.
And where would an Open source project be without the community reporting bugs?

Lastly I can’t see why you had the need to post your post.

I hear you.

I can’t do much about it as you don’t want to make it into a feature.
It would have been nice if you could see the bigger picture.

you can download a trial version of Win81 Enterprise here:
[url]http://technet.microsoft.com/en-gb/evalcenter/hh699156.aspx?ocid=wc-tn-wctc[/url]

on atleast UEFI based systems, the choice of booting from Local HDD makes the boot sequence hang.

So primary boot device cannot be the network.

Would it be too much to ask for a simple thing as how the fog-service aquires the name of the master image and how it should get the name from the database… perhaps I (or my dev) can make a fix.

[this is now]
i.e. old info pulled down and stored in the registry.

[Should be]
[url]http://fogserver/fog/client.php?mac_addy=1234567890ab[/url]

btw as a side note while you’re making a new client… I can’t uninstall the fog-service the traditional way even in it’s Pre-Sysprepped (audit mode) state. The uninstaller runs, the program is removed from the programs list, but the physical files are still located in program files, and the service is still running. It seems the (un)installer for this version is/was broken.

It’s not about methodology, but the way some things are needed to work. I’m sad to see, what could have been a good feature (simple to make for that matter), has been removed. It’s not like a big red frame saying “This computer failed due to X” doesn’t appear in the deployers screen.

On Win81 client / fog 1.2.0, during Sysprep (audit mode) I’ve installed the FOG-Service and activated hostname-change.

After putting the image into OOBE mode, and deploy the image, the hostnames of the deployed computers have the same name as the machine where the master image was created on. If I manually try and rename the other clients, FOG-Service makes sure that the hostname is changed back to what the Master is.

So hostname changer works… but gives the wrong name.