---

Hej,

Det undre mig lidt at en hjælpe fil "programnavn.chm" konstant vil på
nettet.

Hvis jeg åbner den direkte, f.eks for at lære lidt om det pågældende
program, men uden at
åbne programmet, så er det windows programmet C:\windows\hh.exe der vil på
nettet hver gang
jeg kikker på et nyt emne i hjælpefilen.
Åbner jeg den gennem programmet som den høre til, er det den pågældende
program proces der vil
på nettet.

Jeg har efterhånden oplevet det nogle gange, og det irretirer mig, da jeg
ikke ser formålet med at der
sendes informationer fra min maskine til en ukendt IP hver gang jeg læser i
en manuel til et program.
Det er dog langtfra alle chm filer der gør det.

Er der nogle her der kender formålet med denne adfær?

Mvh.

Bo

---

Bo Nielsen wrote:
> Hej,
>
> Det undre mig lidt at en hjælpe fil "programnavn.chm" konstant vil på
> nettet.
>
> Hvis jeg åbner den direkte, f.eks for at lære lidt om det pågældende
> program, men uden at
> åbne programmet, så er det windows programmet C:\windows\hh.exe der vil på
> nettet hver gang
> jeg kikker på et nyt emne i hjælpefilen.
> Åbner jeg den gennem programmet som den høre til, er det den pågældende
> program proces der vil
> på nettet.
>
> Jeg har efterhånden oplevet det nogle gange, og det irretirer mig, da jeg
> ikke ser formålet med at der
> sendes informationer fra min maskine til en ukendt IP hver gang jeg læser i
> en manuel til et program.
> Det er dog langtfra alle chm filer der gør det.
>
> Er der nogle her der kender formålet med denne adfær?
>
> Mvh.
>
> Bo
>
>
En .chm fil indeholder en masse .html filer der kan vises med en
WebBrowser, normalt den variant af Internet Explorer som er indbygget i
hh.exe og html help kontrollen (som loades i alle programmer der bruger
hjælp i .chm format).

Normalt er alle de billeder, javascripts o.s.v. der indgår i
html-siderne i en .chm fil selv lagt ind i .chm filen og html-filerne
linker så til disse interne kopier. Men hvis en eller anden har kludret
i det og lavet html-filer med links til billeder, scripts, stylesheets
eller andre delkomponenter ude på internettet, ja så vil html help
vieweren blindt følge disse links.

For at opklare den præcise årsag kan du gøre følgende:

1. Åben .chm filen
2. Vendt til den beder om adgang til internettet
3. Højreklik på den viste side og bed om "Properties"
4. Hvis der står en URL af typen
mk:@MSITStore:filnavn.chm::/et/eller/andet.htm fortsættes til punkt 5,
ellers er hele siden ude på Internettet og du har lige fulgt et link fra
.chm-filen til Internettet.
5. Højreklik på den viste side og bed om "View Source"
6. Kik efter henvisninger til http, https eller andre eksterne links.
7. Hvis du nåede hertil og i punkt 6 fandt eksterne objekter i en lokal
.chm-fil, så klag til programudgiveren over deres dårlige .chm-fil.


--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

---

Jakob Bøhm wrote:

Hej
Jeg kan ikke nære mig for, at påtale den inkompetente og mangefulde måde
som NetOP håndterer WakeUpLAN på. Selv jeg kan finde ud af, at lave et
script til broadcasting af MagicPackets og pinge remote PC-en indtil
hosten er loadet, for så at etablere remotemanagement. Problemet med WOL
bag NAT routere har I heller ikke løst. Har I overvejet at ansætte
kompetente IT folk til opgaven, så NetOP kan logge på en remote PC som
er slukket og står bag en NAT router, og med kun et klik naturligvis ?

Mvh

---

Peter Plys wrote:
> Jakob Bøhm wrote:
>
> Hej
> Jeg kan ikke nære mig for, at påtale den inkompetente og mangefulde måde
> som NetOP håndterer WakeUpLAN på. Selv jeg kan finde ud af, at lave et
> script til broadcasting af MagicPackets og pinge remote PC-en indtil
> hosten er loadet, for så at etablere remotemanagement. Problemet med WOL
> bag NAT routere har I heller ikke løst. Har I overvejet at ansætte
> kompetente IT folk til opgaven, så NetOP kan logge på en remote PC som
> er slukket og står bag en NAT router, og med kun et klik naturligvis ?
>

1. At kalde det inkompetent er hårde ord fra en som ikke vil stå ved sit
navn.

2. Wake-On-Lan kommandoen i NetOp er en mindre ekstrafunktion, ikke
programmets hovedformål. Derfor er der ikke gjort så meget ud af denne
feature.

3. Der er nogle kendte mangler i den nuværende Wake-On-Lan kode, og
planer om at forbedre funktionaliteten ved lejlighed.

4. Wake-On-Lan i NetOp står sammen med funktioner til f.eks. at slukke
eller reboote Hosten. På ingen af disse funktioner laver vi en blind
antagelse om at brugeren rent faktisk ønsker at fjernbetjene maskinen
som det næste. Det kunne f.eks. være at brugeren bare ønsker at få
maskinen i luften for at bruge den som f.eks. Web-Server eller
AD-server. Så vi sender kommandoen "Tænd PC", "Sluk PC" eller "Reboot
PC" og meddeler når kommandoen er sendt af sted. Hvad brugeren bagefter
gør ved den tændte/slukkede/rebootede PC (hvis overhovedet noget)
blander vi os ikke i.

5. Omvendt antager vi ikke at bare fordi brugeren trykker på en ikon for
en PC som ikke svarer, så ønsker brugeren at tænde den pågældende PC.
Det kan der være mange grunde til at brugeren ikke ønsker.

6. At sende Magic Packets over TCP/IP (med eller uden NAT) lider af den
fundamentale begrænsning at IPv4 og IPv6 nægter at sende datapakker til
PC-er der ikke svarer på ARP / Node solicitation requests fra sidste
router før den PC der skal tændes. Så derfor er vi nødt til at sende en
pakketype som bliver til en broadcast på det netværkssegment hvor PC-en
sidder. Dette generes af at de fleste moderne routere er sat op til at
blokkere de fleste af den slags pakker! Der findes veje udenom, men de
er ikke så lige til som du åbenbart tror.

7. Vi har særdeles kompetente netværksfolk til at skrive koden, men der
er mange forbedringer vi kan lave, og vi er derfor nødt til at vælge
hvad vi laver først og hvad der må vente til en anden god gang.

Slap af Plysbjørn

Jakob

--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

---

Jakob Bøhm skrev:

> 6. At sende Magic Packets over TCP/IP (med eller uden NAT) lider af
> den fundamentale begrænsning at IPv4 og IPv6 nægter at sende
> datapakker til PC-er der ikke svarer på ARP / Node solicitation
> requests fra sidste router før den PC der skal tændes.

I Altiris Deployment Server har de løst det problem ved at lade en
maskine i "nærheden" sende den magiske pakke via Altiris Agenten.

Jeg kender ikke NetOp så jeg ved ikke hvor realistisk foreslaget er.

Her er manualen (tag den øverste reference guide under Deployment
Solution, det er kort beskrevet på side 116 så jeg efter en hurtig søg-
ning i de 575 sider manualen består af):

http://www.altiris.com/Support/Documentation.aspx

Udfordringen er selvfølgelig at lave det tilstrækkeligt sikkert så gud
og hvermand ikke får lov til at tænde klient-pcerne ude fra.

---

On Wed, 20 Jun 2007 12:36:31 +0200, Jakob Bøhm wrote:

> 1. At kalde det inkompetent er hårde ord fra en som ikke vil stå ved sit
> navn.

Jeg vil nu give Plys ret


> 2. Wake-On-Lan kommandoen i NetOp er en mindre ekstrafunktion,

"mindre ekstrafunktion" for en softwarepakke til brug for fjernstyring,
hallo du/I har vist misforstået noget, sorry


> 3. Der er nogle kendte mangler i den nuværende Wake-On-Lan kode, og
> planer om at forbedre funktionaliteten ved lejlighed.

Ikke bare mangler, men direkte tumpet og ubrugelig. Udover det plys nævner,
så kan den heller ikke fiske MAC adressen fra netkortet selvom den fremgår
af "get inventory". MAC adressen skrives også på en dum måde i Jeres
program.


> 4. Wake-On-Lan i NetOp står sammen med funktioner til f.eks. at slukke
> eller reboote Hosten. På ingen af disse funktioner laver vi en blind
> antagelse om at brugeren rent faktisk ønsker at fjernbetjene maskinen
> som det næste. Det kunne f.eks. være at brugeren bare ønsker at få
> maskinen i luften for at bruge den som f.eks. Web-Server eller
> AD-server. Så vi sender kommandoen "Tænd PC", "Sluk PC" eller "Reboot
> PC" og meddeler når kommandoen er sendt af sted.

Ja men der er ingen opfølgning på om PC-en rent faktisk blev tændt, men kun
at kommandoen er fyret af

Jeg synes også at I håndterer WOL fuldkommen amatøragtigt. og jeg skrotte
NetOP fordi dette ikke var lavet elegant og brugbart. Jeg kan huske, at jeg
selv også måtte lave cmd scripts for at få det til at køre automatisk. Det
betyder intet at man hver gang sender MagicPacket og pinger indtil den er
oppe og så starter login scriptet. Hvad er årsagen til at I ikke kan finde
ud af det ?

> blander vi os ikke i.

Jo, for I sælger et program til remotemanagement som ikke fungerer til
formålet uden at man selv er programmør eller særdeles erfaren IT kyndig.
Programmet kostede 10.000 og var en stor skuffelse og I havde heller ikke
noget bruger og supportforum hvor man kunne få svar på tåbelighederne.


> 5. Omvendt antager vi ikke at bare fordi brugeren trykker på en ikon for
> en PC som ikke svarer, så ønsker brugeren at tænde den pågældende PC.
> Det kan der være mange grunde til at brugeren ikke ønsker.

Du vrøvler
Er jobbet ledig hos Jer, så skal Jeg gerne lave noget der virker ?

> 6. At sende Magic Packets over TCP/IP (med eller uden NAT) lider af den
> fundamentale begrænsning at IPv4 og IPv6 nægter at sende datapakker til
> PC-er der ikke svarer på ARP / Node solicitation requests fra sidste
> router før den PC der skal tændes. Så derfor er vi nødt til at sende en
> pakketype som bliver til en broadcast på det netværkssegment hvor PC-en
> sidder. Dette generes af at de fleste moderne routere er sat op til at
> blokkere de fleste af den slags pakker! Der findes veje udenom, men de
> er ikke så lige til som du åbenbart tror.

Ja det er skam en udfordring over NAT men ikke direkte. Også dette har jeg
selv løst, hmm, I er nogle klaphatte. Jeg installerede en tredieparts
firmware i Linksys routeren som kunne broadcaste MagicPackets på
lokalnettet, og vupti - enden på det blev, at jeg bare kunne klikke på mit
script og så ellers vente på at PC-en blev startet og NetOP var klart til
at logge ind

Men jeg skrottede Jeres program fordi der var masser af andre amatørfejl.


> 7. Vi har særdeles kompetente netværksfolk til at skrive koden, men der
> er mange forbedringer vi kan lave, og vi er derfor nødt til at vælge
> hvad vi laver først og hvad der må vente til en anden god gang.

Ja vent bare, for os der skal bruge seriøs remotemanagement finder bare
noget andet. Jeres beslutning er tåbelig, professionel remotemanagement
anvendes i alle tilfælde via en router og i mange tilfælde også udenfor
normal arbejdstid hvor der er behov for at tænde, slukke og reboote.

> Slap af Plysbjørn
Slap selv af, han har jo ret.

Hilsen Tomas
IT helpdesk supporter og datamatiker (kan kun fraråde NetOP)

---

Tomas wrote:
> On Wed, 20 Jun 2007 12:36:31 +0200, Jakob Bøhm wrote:
>
>> 1. At kalde det inkompetent er hårde ord fra en som ikke vil stå ved sit
>> navn.
>
> Jeg vil nu give Plys ret
>
Og du er også anonym...
>
>> 2. Wake-On-Lan kommandoen i NetOp er en mindre ekstrafunktion,
>
> "mindre ekstrafunktion" for en softwarepakke til brug for fjernstyring,
> hallo du/I har vist misforstået noget, sorry
>
>

At lave Wake-On-Lan er en mindre ekstrafunktion i forhold til de ting
som er hoveformålet med NetOp: Styring af PC-en EFTER den er blevet
tændt (hvilket den ofte er i forvejen).

>> 3. Der er nogle kendte mangler i den nuværende Wake-On-Lan kode, og
>> planer om at forbedre funktionaliteten ved lejlighed.
>
> Ikke bare mangler, men direkte tumpet og ubrugelig. Udover det plys nævner,
> så kan den heller ikke fiske MAC adressen fra netkortet selvom den fremgår
> af "get inventory". MAC adressen skrives også på en dum måde i Jeres
> program.
>

At fiske MAC-adressen til WOL automatisk er noget der overvejes, men som
endnu ikke er lavet (og som vi heller ikke reklamerer for).

Den noget specielle måde at skrive MAC-adresser på i NetOp
(0x0123456789AB i stedet for det officielle 01-23-45-67-89-AB) et et
levn fra ca. 1995, vi har valgt ikke at ændre notationen af hensyn til
brugere som er vandt til den måde det allerede fungerer på.


>
>> 4. Wake-On-Lan i NetOp står sammen med funktioner til f.eks. at slukke
>> eller reboote Hosten. På ingen af disse funktioner laver vi en blind
>> antagelse om at brugeren rent faktisk ønsker at fjernbetjene maskinen
>> som det næste. Det kunne f.eks. være at brugeren bare ønsker at få
>> maskinen i luften for at bruge den som f.eks. Web-Server eller
>> AD-server. Så vi sender kommandoen "Tænd PC", "Sluk PC" eller "Reboot
>> PC" og meddeler når kommandoen er sendt af sted.
>
> Ja men der er ingen opfølgning på om PC-en rent faktisk blev tændt, men kun
> at kommandoen er fyret af
>

WOL i sig selv giver IKKE automatisk besked om at maskinen nu er tændt,
og alle de foreslåede måder at teste på om maskinen så er blevet tændt
afhænger kraftigt af maskinens konfiguration: Langt fra alle maskiner
svarer på ping, langt fra alle maskiner er sat til at svare på
NetOp-opkald (desværre) o.s.v.

> Jeg synes også at I håndterer WOL fuldkommen amatøragtigt. og jeg skrotte
> NetOP fordi dette ikke var lavet elegant og brugbart. Jeg kan huske, at jeg
> selv også måtte lave cmd scripts for at få det til at køre automatisk. Det
> betyder intet at man hver gang sender MagicPacket og pinger indtil den er
> oppe og så starter login scriptet. Hvad er årsagen til at I ikke kan finde
> ud af det ?
>

Der er ikke noget i NetOp som hedder login-scripts! Men hvis du mener
at vente på at maskinen er oppe og derefter lave en NetOp-forbindelse,
så har etablering af en NetOp-forbindelse så tilpas lang timeout at man
for de fleste maskiner kan slippe af sted med at trykke "Wake On Lan" og
derefter "Call". For maskiner der er længe om at boote drikker man bare
en kop kaffe eller fjernbetjener en anden maskine inden man forsøger at
tage forbindelse.

>> blander vi os ikke i.
>
> Jo, for I sælger et program til remotemanagement som ikke fungerer til
> formålet uden at man selv er programmør eller særdeles erfaren IT kyndig.
> Programmet kostede 10.000 og var en stor skuffelse og I havde heller ikke
> noget bruger og supportforum hvor man kunne få svar på tåbelighederne.
>
>

NetOp Remote Control fungerer særdeles godt til remote management, helt
uden programmering fra slutbrugerens side. Men hvis du prøver at få et
program til at gøre noget andet end det er meningen at det skal gøre så
ryger du hurtigt ud i programmering og Storm P løsninger.

Med hensyn til at få svar på dine tåbeligheder så er der altså en
supportfunktion med mennesker i den anden ende. Det er bare ikke et
offentligt supportforum hvor tilfældige forbipasserende skal trækkes med
dine misforståelser.



>> 5. Omvendt antager vi ikke at bare fordi brugeren trykker på en ikon for
>> en PC som ikke svarer, så ønsker brugeren at tænde den pågældende PC.
>> Det kan der være mange grunde til at brugeren ikke ønsker.
>
> Du vrøvler

Nej da, det bygger på erfaring, måske trykkede brugeren på den forkerte
PC, måske ønskede brugeren ligefrem at sikre sig at maskinen var
slukket. Bare et par eksempler.

> Er jobbet ledig hos Jer, så skal Jeg gerne lave noget der virker ?
>

Din forvirrede og fordømmende holdning lyder ikke befordrende for et
frugtbart samarbejde...

>> 6. At sende Magic Packets over TCP/IP (med eller uden NAT) lider af den
>> fundamentale begrænsning at IPv4 og IPv6 nægter at sende datapakker til
>> PC-er der ikke svarer på ARP / Node solicitation requests fra sidste
>> router før den PC der skal tændes. Så derfor er vi nødt til at sende en
>> pakketype som bliver til en broadcast på det netværkssegment hvor PC-en
>> sidder. Dette generes af at de fleste moderne routere er sat op til at
>> blokkere de fleste af den slags pakker! Der findes veje udenom, men de
>> er ikke så lige til som du åbenbart tror.
>
> Ja det er skam en udfordring over NAT men ikke direkte. Også dette har jeg
> selv løst, hmm, I er nogle klaphatte. Jeg installerede en tredieparts
> firmware i Linksys routeren som kunne broadcaste MagicPackets på
> lokalnettet, og vupti - enden på det blev, at jeg bare kunne klikke på mit
> script og så ellers vente på at PC-en blev startet og NetOP var klart til
> at logge ind

Ja, der er flere scenarier hvor vores kode endnu ikke udnytter alle de
huller der kan lukke WOL pakker igennem diverse routere. Det har jeg
svaret på en gang.

>
> Men jeg skrottede Jeres program fordi der var masser af andre amatørfejl.
>

Rapporterede du dem til vores support? Er det rigtige fejl eller bare
flere misforståelser?

>
>> 7. Vi har særdeles kompetente netværksfolk til at skrive koden, men der
>> er mange forbedringer vi kan lave, og vi er derfor nødt til at vælge
>> hvad vi laver først og hvad der må vente til en anden god gang.
>
> Ja vent bare, for os der skal bruge seriøs remotemanagement finder bare
> noget andet. Jeres beslutning er tåbelig, professionel remotemanagement
> anvendes i alle tilfælde via en router og i mange tilfælde også udenfor
> normal arbejdstid hvor der er behov for at tænde, slukke og reboote.
>
Ja, det ved vi godt. Og da de fleste routere ikke er sat specielt op
til at slippe WOL igennem har vi prioriteret WOL ret lavt i forhold til
de mange andre funktioner som ikke har problemer med at krydse routere.

>> Slap af Plysbjørn
> Slap selv af, han har jo ret.
>
Nej det har han ikke, han synes bare rønnebærene er sure og overfalder
en tilfældig NetOp-mand i en tilfældig nyhedsgruppe.

--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this posting is hasty, not binding and may not be right
Information in this posting is not the official position of Danware Data
A/S, only the personal opinions of the author.

---

On Mon, 02 Jul 2007 14:27:35 +0200, Jakob Bøhm wrote:

Hej Jacob
Jeg må blande mig lidt, for du er helt galt på den og ved tilsyneladende
ikke nok om IT.

> At lave Wake-On-Lan er en mindre ekstrafunktion i forhold til de ting
> som er hoveformålet med NetOp: Styring af PC-en EFTER den er blevet
> tændt (hvilket den ofte er i forvejen).

Helt uenig. WOL er en vigtig funktion.

> At fiske MAC-adressen til WOL automatisk er noget der overvejes

Se at få det lavet, inden I mister for mange kunder.

> Den noget specielle måde at skrive MAC-adresser på i NetOp
> (0x0123456789AB i stedet for det officielle 01-23-45-67-89-AB) et et
> levn fra ca. 1995, vi har valgt ikke at ændre notationen af hensyn til
> brugere som er vandt til den måde det allerede fungerer på.

Et tåbeligt valg. Ingen bruger denne term mere. Jeg selv blev irriteret
over at adressen ikke kunne cut/pastes uden at omskrives, og at den ikke
kunne sniffes automatisk fra netkortet, sådan som en DHCP router kan gøre
for DHCP klienterne.

> WOL i sig selv giver IKKE automatisk besked om at maskinen nu er tændt,

Nej det tror jeg alle ved og det er heller ikke det der bliver påstået.

> og alle de foreslåede måder at teste på om maskinen så er blevet tændt
> afhænger kraftigt af maskinens konfiguration: Langt fra alle maskiner
> svarer på ping, langt fra alle maskiner er sat til at svare på
> NetOp-opkald (desværre) o.s.v.

Suk, suk, man kunne jo bare eksekvere CALL i automatiske intervaller. Også
det blev jeg irriteret over, at NetOP ikke kunne.

> Der er ikke noget i NetOp som hedder login-scripts!
Nej, og derfor skal man selv lavet et og sætte det ind i "custom", så det
kan eksekveres automatisk fra menuen. På denne måde kan man overkomme at
NetOP ikke kan køre en WOL og CALL i et og samme arbejdsgang.

> Men hvis du mener
> at vente på at maskinen er oppe og derefter lave en NetOp-forbindelse,
> så har etablering af en NetOp-forbindelse så tilpas lang timeout at man
> for de fleste maskiner kan slippe af sted med at trykke "Wake On Lan" og
> derefter "Call". For maskiner der er længe om at boote drikker man bare
> en kop kaffe eller fjernbetjener en anden maskine inden man forsøger at
> tage forbindelse.

Timeouts kan heller ikke sættes i login fanen

> NetOp Remote Control fungerer særdeles godt til remote management, helt
> uden programmering fra slutbrugerens side.

Nå, så har du vidst aldrig opdaget at brugerne har en softwarefirewall, som
mildest talt er umulig at lave rules til NetOP til. Det burde være nok med
hostfilens exenavn og portnummer, men I bruger to exe filer som chainer på
en kryptisk måde som jeg ikke gider komme nærmere ind på her, men
pcAnywhere er ligetil at lave firewallrules til. Dette problem gjorde at
også jeg måtte droppe NetOP, fordi det gav problemer på hostsiden og
softwarefirewall'en.

> supportfunktion med mennesker i den anden ende.

Gider ikke bruge software, hvor supportfora bliver gemt internt. Et
supportfora skal være offentligt, enten via et bulletinboard eller en
newsgroup.

> Det er bare ikke et
> offentligt supportforum hvor tilfældige forbipasserende skal trækkes med
> dine misforståelser.

Firmaet som laver NetOP har misforstået en masse. Det er professionelle som
bruger programmet og som opdager mange fejl og mangler, som man vil
diskutere med andre om.

> Ja, der er flere scenarier hvor vores kode endnu ikke udnytter alle de
> huller der kan lukke WOL pakker igennem diverse routere.

Fix det.

> Rapporterede du dem til vores support? Er det rigtige fejl eller bare
> flere misforståelser?

Ja der er mange fejl. Bl.a. kan man ikke være sikker på at filer som
overføres er overført fejlfrit, derfor skal de pakkes med rar/zip inden for
at få CRC på dem.


>> Ja vent bare, for os der skal bruge seriøs remotemanagement finder bare
>> noget andet. Jeres beslutning er tåbelig, professionel remotemanagement
>> anvendes i alle tilfælde via en router og i mange tilfælde også udenfor
>> normal arbejdstid hvor der er behov for at tænde, slukke og reboote.
>>
> Ja, det ved vi godt. Og da de fleste routere ikke er sat specielt op
> til at slippe WOL igennem har vi prioriteret WOL ret lavt i forhold til
> de mange andre funktioner som ikke har problemer med at krydse routere.

Fix det hvis I kan finde ud af det

> overfalder
> en tilfældig NetOp-mand i en tilfældig nyhedsgruppe.

Enig, det har du ikke fortjent. Men NetOP kunne have været markedsførende
hvis ikke ledelsen hos Jer var så dårlig. Programmet har perspektiver, men
mangler fornyelse og opdatering, samt at I lærer af de proffe kunder. Noget
jeg husker som irriterende var at tastetryk ikke blev overført korrekt til
hosten, bl.a. ctrl+z var ikke fortryd, og capslock forblev hos hosten efter
man var logget af. osv...
Og så manglede der drag/drop support fra Windows Explorer til hostens
folders.

Venligst Jonas

---

On Fri, 6 Jul 2007 02:24:58 +0200, Jonas Andersen
<jonas.andersen@yahoo.mail> wrote:

>Hej Jacob
>Jeg må blande mig lidt, for du er helt galt på den og ved tilsyneladende
>ikke nok om IT.

Hej Jonas.

Er du egentligt den samme som Tomas og Peter Plys?

Tomas "giver Plys ret", men poster som sådan fra den samme pudsige
newsserver. Det behøver selvfølgelig ikke at betyde noget.

Du "blander dig lidt" i tråden, omend du skriver på samme måde som
Tomas: "NetOP" i stedet for "NetOp", "Jer" i stedet for "jer", "IT" i
stedet for "it". Peter Plys skriver også "it", og både Tomas og Peter
Plys skriver "remotemanagement" i stedet for "remote management", samt
har mellemrum før spørgsmålstegn.

Det undrer mig lidt. Det her er naturligvis ikke en anklage eller for
den sags skyld sprogbrok, men jeg undrede mig blot over sammenfaldene
- altså om det var samme person, eller måske blot folk fra samme firma
som brugte de samme notationer. Er det samme person, vil det
naturligvis slække noget på troværdigheden i øvrigt.


Det er i øvrigt ret sjovt, at hvis man kigger på øvrige indlæg postet
fra samme "anonyme" IP-adresse (dvs. en TOR-udgang), finder man en
håndfuld indlæg, hvor skribentformen er den samme (mellemrum før
spørgsmålstegn, "Jeres" i stedet for "jeres"). Det kan godt være, at
der er en overordnet anonymitet, men det er stadigvæk ret let at finde
sammenhængende indlæg, hvor både IP-adresse og skriveform passer og
dermed lave en intern sammenkædning.

... og det uanset om kalder sig for Mona Frederiksen og snakker om
erfaring med mænd i dk.helbred.slank, TheMonster og snakker om
proteinpulver i dk.helbred eller Offroader og snakker om
forsikringsbander i dk.forbruger

--
- Peter Brodersen
Kendt fra Internet

---

Peter Brodersen wrote:

> Det er i øvrigt ret sjovt, at hvis man kigger på øvrige indlæg postet
> fra samme "anonyme" IP-adresse (dvs. en TOR-udgang), finder man en
> håndfuld indlæg,

Hej Peter (altså ikke Plys)
Jeg er ny Tor-bruger og ville da gerne vide hvordan du ser hvilke IP
numre der bruges. Jeg bruger altså Tor via aioe, hvilket jeg har fået at
vide, vil maskere IP-en og beskytte brugeren mod netspioner som dig
Men jeg ser ikke IP nummeret i headeren, men en tekststreng, så hvordan
vil du så finde mine indlæg på usenet?
Tager du ikke fejl, og bluffer du ikke bare?
Du kører vel en Hamsterserver og laver statistik på NNTP headeren, right?
Men Tor har jo kun få NNTP exitservers, som hele verden kan bruge, så
man kan vel ikke udlede at alle indlæg fra samme IP, så kommer fra samme
skribent, eller hvad?

---

Jonas Andersen wrote:
> On Mon, 02 Jul 2007 14:27:35 +0200, Jakob Bøhm wrote:
>
> Hej Jacob
> Jeg må blande mig lidt, for du er helt galt på den og ved tilsyneladende
> ikke nok om IT.
>
Sludder og flere beskyldninger, i øvrigt tak til Peter Brodersen for
hans indlæg, noget jeg ikke selv turde skrive i denne tråd.

>> At lave Wake-On-Lan er en mindre ekstrafunktion i forhold til de ting
>> som er hoveformålet med NetOp: Styring af PC-en EFTER den er blevet
>> tændt (hvilket den ofte er i forvejen).
>
> Helt uenig. WOL er en vigtig funktion.
>

Alle kunder har deres yndlingsfunktioner som lige den kunde synes er
vigtigere end alt andet i hele verden. Men i det store billede er
WOL-kommandoen i NetOp bare et lille funktion i et stort program.

>> At fiske MAC-adressen til WOL automatisk er noget der overvejes
>
> Se at få det lavet, inden I mister for mange kunder.
>
Der er andre ting der haster mere...

>> Den noget specielle måde at skrive MAC-adresser på i NetOp
>> (0x0123456789AB i stedet for det officielle 01-23-45-67-89-AB) et et
>> levn fra ca. 1995, vi har valgt ikke at ændre notationen af hensyn til
>> brugere som er vandt til den måde det allerede fungerer på.
>
> Et tåbeligt valg. Ingen bruger denne term mere. Jeg selv blev irriteret
> over at adressen ikke kunne cut/pastes uden at omskrives, og at den ikke
> kunne sniffes automatisk fra netkortet, sådan som en DHCP router kan gøre
> for DHCP klienterne.
>
Det kan da godt være at du aldrig har haft brug for de andre
NetOp-funktioner hvor man skal skrive/gemme MAC-adresser og derfor ikke
har nogle MAC-adresser liggende i den gamle notation, men det betyder
ikke at der ikke er andre der har det.

>> WOL i sig selv giver IKKE automatisk besked om at maskinen nu er tændt,
>
> Nej det tror jeg alle ved og det er heller ikke det der bliver påstået.
>
Der er mange der ikke ved hvordan WOL virker, men tak fordi du giver mig
ret i noget.

>> og alle de foreslåede måder at teste på om maskinen så er blevet tændt
>> afhænger kraftigt af maskinens konfiguration: Langt fra alle maskiner
>> svarer på ping, langt fra alle maskiner er sat til at svare på
>> NetOp-opkald (desværre) o.s.v.
>
> Suk, suk, man kunne jo bare eksekvere CALL i automatiske intervaller. Også
> det blev jeg irriteret over, at NetOP ikke kunne.
>
Hvis man skal bruge NetOp-forbindelsen interaktivt er der ikke meget
sjov ved en funktion der står og ringer op og ringer op igen og igen
helt uden menneskelig indgriben. Hvis man skal bruge NetOp-forbindelsen
til noget automatiseret indeholder vores automatiserings-funktioner skam
muligheden for automatisk at prøve igen (Står under "Global Settings,
Advanced")

>> Der er ikke noget i NetOp som hedder login-scripts!
> Nej, og derfor skal man selv lavet et og sætte det ind i "custom", så det
> kan eksekveres automatisk fra menuen. På denne måde kan man overkomme at
> NetOP ikke kan køre en WOL og CALL i et og samme arbejdsgang.
>
Interessant brug af Custom-punktet, som egentlig var lavet til noget andet.

>> Men hvis du mener
>> at vente på at maskinen er oppe og derefter lave en NetOp-forbindelse,
>> så har etablering af en NetOp-forbindelse så tilpas lang timeout at man
>> for de fleste maskiner kan slippe af sted med at trykke "Wake On Lan" og
>> derefter "Call". For maskiner der er længe om at boote drikker man bare
>> en kop kaffe eller fjernbetjener en anden maskine inden man forsøger at
>> tage forbindelse.
>
> Timeouts kan heller ikke sættes i login fanen
>
Nej, det er sjældent noget man behøver at justere og derfor skal de få
brugere som ønsker andre timeout-værdier ned og rette dette manuelt i
NetOp.INI, som beskrevet i vores knowledgebase.

>> NetOp Remote Control fungerer særdeles godt til remote management, helt
>> uden programmering fra slutbrugerens side.
>
> Nå, så har du vidst aldrig opdaget at brugerne har en softwarefirewall, som
> mildest talt er umulig at lave rules til NetOP til. Det burde være nok med
> hostfilens exenavn og portnummer, men I bruger to exe filer som chainer på
> en kryptisk måde som jeg ikke gider komme nærmere ind på her, men
> pcAnywhere er ligetil at lave firewallrules til. Dette problem gjorde at
> også jeg måtte droppe NetOP, fordi det gav problemer på hostsiden og
> softwarefirewall'en.
>
Sludder, NetOp er lavet særdeles firewall-venligt: Der er kun 1 program
som skal igennem firewallen (nemlig det program som alle ikonerne peger
på), og der skal kun åbnes for en enkelt port. Alle de andre processer
holder sig pænt væk fra at snakke direkte med netværket på egen hånd.

>> supportfunktion med mennesker i den anden ende.
>
> Gider ikke bruge software, hvor supportfora bliver gemt internt. Et
> supportfora skal være offentligt, enten via et bulletinboard eller en
> newsgroup.
>
Der er ikke noget "gemt" supportfora, og din ide om at alle verdens
produkter skal supporteres via nyhedsgrupper etc. er altså langt ude.

>> Det er bare ikke et
>> offentligt supportforum hvor tilfældige forbipasserende skal trækkes med
>> dine misforståelser.
>
> Firmaet som laver NetOP har misforstået en masse. Det er professionelle som
> bruger programmet og som opdager mange fejl og mangler, som man vil
> diskutere med andre om.
Problemet er at de fleste supportfora drukner i brokkehoveder der
slynger om sig med fikse ideer og løse beskyldninger.

>
>> Ja, der er flere scenarier hvor vores kode endnu ikke udnytter alle de
>> huller der kan lukke WOL pakker igennem diverse routere.
>
> Fix det.
>
>> Rapporterede du dem til vores support? Er det rigtige fejl eller bare
>> flere misforståelser?
>
> Ja der er mange fejl. Bl.a. kan man ikke være sikker på at filer som
> overføres er overført fejlfrit, derfor skal de pakkes med rar/zip inden for
> at få CRC på dem.
>
Jeg spurgte om du havde rapporteret det til vores officielle support,
ikke om du havde lyst til at komme med flere påstande. I øvrigt laver
NetOp skam checksummer på overførte filer for at opdage mislykkede
overførsler og det er en del versioner siden der sidst blev fundet
alvorlige fejl i den del af koden.

>
>>> Ja vent bare, for os der skal bruge seriøs remotemanagement finder bare
>>> noget andet. Jeres beslutning er tåbelig, professionel remotemanagement
>>> anvendes i alle tilfælde via en router og i mange tilfælde også udenfor
>>> normal arbejdstid hvor der er behov for at tænde, slukke og reboote.
>>>
>> Ja, det ved vi godt. Og da de fleste routere ikke er sat specielt op
>> til at slippe WOL igennem har vi prioriteret WOL ret lavt i forhold til
>> de mange andre funktioner som ikke har problemer med at krydse routere.
>
> Fix det hvis I kan finde ud af det
Forstår du ordet "prioriteret"?

>
>> overfalder
>> en tilfældig NetOp-mand i en tilfældig nyhedsgruppe.
>
> Enig, det har du ikke fortjent. Men NetOP kunne have været markedsførende
> hvis ikke ledelsen hos Jer var så dårlig. Programmet har perspektiver, men
> mangler fornyelse og opdatering, samt at I lærer af de proffe kunder. Noget
> jeg husker som irriterende var at tastetryk ikke blev overført korrekt til
> hosten, bl.a. ctrl+z var ikke fortryd, og capslock forblev hos hosten efter
> man var logget af. osv...
Selvfølgelig bliver tastetryk overført korrekt. Ctrl+Z er NetOp's hotkey
for Zoom og bliver derfor slet ikke overført, brug i stedet
Alt+Backspace eller vælg en anden hotkey for Zoom. At Caps Lock, Scroll
Lock og Num lock bliver stående på den indstilling man efterlader dem i
er en logisk konsekvens af princippet om at når man fjernbetjener skal
det hele være som om man sidder foran den anden computers skærm og tastatur.

> Og så manglede der drag/drop support fra Windows Explorer til hostens
> folders.
>
Indrømmet.
> Venligst Jonas
eller hvad du nu hedder...

--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Information in this posting is not the official position of Danware
Data A/S, only the personal opinions of the author.