Le cassette postali condivise consentono a un gruppo di persone di monitorare e inviare posta elettronica da un indirizzo di posta elettronica comune, come info@mecdata.it. Quando un utente del gruppo risponde a un messaggio inviato alla cassetta postale condivisa, il messaggio di risposta sembrerà inviato dalla cassetta postale condivisa, non dal singolo utente.
Le cassette postali condivise vengono usate quando più persone devono accedere alla stessa cassetta postale, ad esempio un’informazione aziendale o un indirizzo di posta elettronica di supporto, una reception o un’altra funzione che potrebbe essere condivisa da più persone.
Le cassette postali condivise includono un calendario condiviso ed una rubrica condivisa.
Licenze: La cassetta postale condivisa può archiviare fino a 50 GB di dati senza assegnare una licenza. Per volumi più elevati, è necessario assegnare una licenza alla cassetta postale
Utenti esterni: Non è possibile concedere agli utenti esterni all’azienda (ad esempio, utenti con un account Gmail) l’accesso alla cassetta postale condivisa
Conversione delle cassette postali: È possibile convertire le cassette postali utente in cassette postali condivise.
Troppi utenti: Quando sono presenti troppi utenti designati che accedono contemporaneamente a una cassetta postale condivisa (è consigliabile non più di 25), è possibile che non riescano a connettersi a questa cassetta postale o abbiano incoerenze come i messaggi duplicati nella posta in uscita
When you connect to ftp server create with Microsoft IIS using Filezilla Client you should have this error
GnuTLS error -48: Key usage violation in certificate has been detected. Could not connect to server
Your configuration settings are something like this :
The problem is with self signed certificate on server side. This is a problem with the certificate generation of Microsoft IIS, as it does not allow the certificates to be used for digital signatures.
This is a server-side issue, and it did not appear previously because earlier versions of FileZilla shipped with a GnuTLS version that didn’t make this check.
Quoting Tim Kosse’s post in the FileZilla forum thread:
In any case, the problem is with your server’s X.509 certificate chain: Either the server certificate itself or another certificate in the chain has a key usage restriction that is violated. For example a certificate with a key usage restriction to signing cannot be used to authenticate TLS connections. See section 4.2.1.3 of RFC 5280.
This is a problem with the certificate generation of Microsoft IIS (but may also happen if you incorrectly generated a certificate with another method), as it does not allow the certificates to be used for digital signatures. OpenSSL is much more relaxed about this and won’t fail because of it, so it may work with other apps.
On the client side, you can either disable TLS, downgrade to an earlier version of FileZilla (neither of these is recommended due to potential security risks), or use a different client which uses another library such as OpenSSL for now.
This needs to be done on the server side, Yobviously.you can generate the certificate with PowerShell instead until the issue is fixed by Microsoft. Open PowerShell in admin mode.
The following powershell command will create our self-signed certificate for our binding and store it in the Personal Store (Note how I also store a reference to the certificate in a variable called $cert this will be needed further on):
$binding = "192.168.1.70" $cert = New-SelfSignedCertificate -DnsName "$binding" -CertStoreLocation "cert:\LocalMachine\My"
However, this is not enough to make the certificate work for HTTPS in our browser. We need to add our newly created certificate to the Trusted Root Certificate store. To do this we take our $cert variable which references our created certificate and add it to our Trusted Root Certificate store like so:
$DestStore = new-object System.Security.Cryptography.X509Certificates.X509Store([System.Security.Cryptography.X509Certificates.StoreName]::Root,"localmachine") $DestStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite) $DestStore.Add($cert) $DestStore.Close()
Now you have to set the new certicate on your ftp site using IIS Admin.
You ar trying to backup a sqlserver db on mapped network drive. You have already mapped the drive in Windows and you can see that drive in Windows Explorer. You are not able to see the drive which is mapped when you open the backup procedure using SqlServer Managment studio.
First of all you not need the previous mapped network drive created by Explorer. You have to create this drive using SqlServer, and you’ll not be able to see it using Exploer.
You need to execute below to enable xp_cmdshell as its disabled by default due to security reasons. (Please turn off again once you done with the work)
Using SSMS execute thesse commands :
EXEC sp_configure 'show advanced options', 1; GO RECONFIGURE; GO
EXEC sp_configure 'xp_cmdshell',1 GO RECONFIGURE GO
After this you ‘ll have a positive reaction a this command that using SSMS you should use for testing previous operations :
EXEC XP_CMDSHELL 'Dir C:'
To map network drive you have to use the same command that you should use over Windows ysig command prompt :
'net use Z: \\networkShare\Test'
So, using SSMS you have to run the command
EXEC XP_CMDSHELL 'net use Z: \\networkShare\Test'
Now you should test this connection with the command
EXEC XP_CMDSHELL 'Dir Z:'
but, the most important goal, is tha you’ll be able to see teh drive Z during backup proceure over SSMS
The above command will work and completes successfully without asking the user to provide a username/password if the user has authorized access to this network share. If not, But the easy way is to use the “net use” command on the command prompt line explained above.
net use Z: \\networkShare\Test /u:domainname\username password
So, using SSMS you have to run the command
EXEC XP_CMDSHELL 'net use Z: \\networkShare\Test /u:domainname\username password'
You are are using vmware workstation and you have mount on your computer a PCIe LPT card. You are unable to connect this LPT port to your guest vm.
Uninstall VM-Ware and to Reinstallit
You cannot see nfs datastore on esxi. Try to do the munting, but the procedure fails saying that the datastore already exists.
To resolve this issue, remove and re-add the datastore via the command line
esxcli storage nfs list
Run this command to mount the NFS datastore:
esxcli storage nfs add -H NFS_IP|NFS_HOSTNAME -s Share_mount_point_on_the_NFS -v DatastoreName
You downloaded and installed a Bitdefender Gravityzone virtual appliance and you need to test the product but you have only a free trial license that you can you use only on cloud solution exclusively.
To register for a trial for the on premise GravityZone, please use this link: https://www.bitdefender.com/business/free-trials/ (You will need to use a different email address).
When filling out the required form, select only one of these on-premises products: Bitdefender Security for Virtualized Environments, Bitdefender GravityZone Security for Endpoints, Bitdefender GravityZone Security for Exchange, Bitdefender GravityZone Security for Mobile.
When you have this error, it means that your system has by default, a line in /etc/fstab which indicates that if there is an error in the file system, that it should go into read-only mode, to prevent further corruption or dataloss.
You could use lsblk to determine the partition name.
Use the command
sudo fsck -f /dev/sdxxwhere “sdxx” is the partition of the hard drive that Linux resides on
