Siamo particolarmente orgogliosi di comparire, unici italiani, all’interno dell’articolo in compagnia di grandi gruppi internazionali e il tutto, se è possibile, viene reso ancora più gratificante dal fatto che: anche il pezzo è stato pubblicato da un grande “portale” straniero, come Alfemminile.com.

Oltre a ringraziare pubblicamente Fabiana Berna, autrice dell’articolo, ci teniamo a sottolineare che siamo gli unici italiani presenti; perché dopo essere stati i primi a dividere la lista in pacchetti ormai più di 4 anni fa, cerchiamo ogni giorno di “tenere botta” con la concorrenza del colosso spagnolo Zankyou e dei francesi di Ameliste.

Potete trovare l’articolo completo qui.

Scegli la lista nozze Made in Italy, scegli inviaggiodinozze.it!

Potete seguire inViaggiodiNozze.it anche su Facebook, Google+ e Twitter

UFFICIO STAMPA
www.inviaggiodinozze.it

Scarica il comunicato stampa

In questi anni inViaggiodiNozze.it ha portato grandi novità nell’ambito delle liste nozze online, siamo stati i primi nel 2008 a dividere la lista nozze in pacchetti, in modo che anche gli invitati avessero la possibilità di partecipare in un modo più personale e divertente al regalo, scegliendo quale pezzettino di sogno regalare agli sposi.

I successi e le innovazioni create in questi anni ci spingono a voler fare ancora di più: stiamo lavorando a una nuova versione del portale con tante novità, ancora una volta vorremmo lasciarvi a bocca aperta e ancora una volta con voi potremmo riscrivere la storia delle liste nozze online.

Potete seguire inViaggiodiNozze.it anche su Facebook, Google+ e Twitter

UFFICIO STAMPA
www.inviaggiodinozze.it

Scarica il comunicato stampa

Riprendo a parlare di un argomento che dopo uno spumeggiate 2009 ho un po’ trascurato…

Il SEO è una scienza altamente inesatta, complessa e di cui non si conoscono mai bene e fino in fondo le regole.

Ovvio le “regole base” tutti i nuovi esperti di SEO, anche quelli fai-da-te le conoscono, ma non sono elencabili tutti i parametri che incidono in maniera minore ma sempre significativa.

Tra queste piccole peculiarità che fino a poco tempo fa io stesso trascuravo c’è:

cioè più è lontata la scadenza del dominio, più si prevede che il sito sarà stabile nel tempo, migliore sarà il suo valore di indicizzazione.

La seconda, su cui si sa ancora meno e che ho sperimentato in prima persona qualche settimana fa:

• i dati dell’owner del dominio

Se mantenete sempre gli stessi dati, sarete considerati stabili e affidabili… ma se DOVETE

cambiare i dati, SARETE PENALIZZATI.

Maggiore è la stabilità dei dati di registrazione migliore sarà l’indicizzazione.

Ma se come me, dovete assolutamente variare i dati del proprietario? Google, senza pietà, vi retrocederà nella SERP!

Di quanto?
Beh questo non so da cosa dipenda, ma io posso citare il mio caso.

Mesi fa ho iniziato un lavoro di indicizzazione di un sito con la chiave “lista nozze“, una chiave da 40.000 ricerche/mese (fonte:Google), riuscendo a portare il sito da oltre la cinquantesima posizione alla decima, prima pagina!

Dopo aver raggiunto questo risultato mi accorgo di dover cambiare i dati dell’owner del dominio, effettuo il cambio con il NIC e il sito inizia a SPROFONDARE… dopo 3 settimane ci siamo attestati 20esimi, abbiamo perso 1 pagina!
Oggi che scrivo abbiamo iniziato a risalire, ma non sappiamo ancora quanta credibilità ha perso www.inviaggiodinozze.it per la chiave lista nozze.
Ci tengo anche a dire che con altre chiavi come “lista di nozze” e “lista nozze online” (forse meno competitive) il “danno” collaterale è stato inferiore, solo 3/4 posizioni.

Illustrata per sommi capi la situazione, mi trovo con il problema specifico di “joinare” al Dominio AD della rete A 2 client che risiedono sulla rete B.
Come si può far “vedere” ai client il controller di dominio della rete A, tenendo presente i problemi che ereditiamo dal natting?

Teniamo sempre a mente che la rete A ha una classe 192.168.0.0/24, la rete B ha una classe 192.168.10.0/24, ma vede il network A, a causa della nattatura, come 10.0.0.0/24.
Se il DC si A è 192.168.0.1 all’interno di B il server è raggiungibile come 10.0.0.1.
Vi risparmio un po’ di fatica: non potete impostare 192.168.0.1 come DNS server i pacchetti non passerebbero la VPN e se impostate 10.0.0.1 come Primary DNS in ogni caso il Controller risponderebbe con parametri che appartengono ad un’altra rete.

Soluzione?
semplice, “drogate” il DNS della rete B per risolvere correttamente il Dominio nattato A.

esempio pratico:
il DNS di B avrà sicuramente delle entry per miodominioB.local,
aggiungete una nuova zona miodominioA.local create un “A Record“ per il DC in 10.0.0.1
poi create la zona _mscds.miodominioA.local all’interno della quale create un record SRV _ldap su protocollo _tcp per il DC che avete inserito manualmente.
fate la join al dominio e se il DC è un Windows Server 2008 il gioco è fatto!

Dovete entrare nel pannello di controllo avanzato dei DNS e dopo aver creato i 2 CNAME richiesti creare il record SRV

come nome inserite:
servizio.protocollo.nome
esempio: _sipfederationtls._tcp.dominio.com

TTL 3600 (1 ora)
Tipo SRV

valore (in base alla sintassi di register.it):
priority weight portnumber target
esempio: 100 1 5061 sipfed.online.lync.com

Per verificare:
start, esegui, cmd

C:\>nslookup
Server predefinito: dns.interbusiness.it
Address: 151.99.125.2

> set type=all
> _sipfederationtls._tcp.dominio.com
Server: dns.interbusiness.it
Address: 151.99.125.2

Risposta da un server non autorevole:
_sipfederationtls._tcp.dominio.com SRV service location:
priority = 100
weight = 1
port = 5061
svr hostname = sipfed.online.lync.com