aledeniz's questions

I am migrating VMs from Hyper-V to Azure using the integration among SCVMM and the Azure Replication Service.

For a given VM, I performed successfully the test failover, I validated the outcome, I cleaned it up, the failover has completed successfully, and the portal is giving me the options to either:

• Commit
• Change recovery point
• Complete Migration
• Disable Replication.

Problem is, for this given VM I'd like to rollback the migration instead, so that the Hyper-V VM becomes the primary and the protection restarts.

I understand I could disable replication and reconfigure a new replication, but that would mean starting protection from scratch.

Is there a way to achieve a rollback at this point in time without disabling replication?

I have an issue with the Windows System State Analyzer 3.0.

The tool takes snapshots of the status of file systems, drivers, registry and services statuses, but when I try to compare those, it fails the file system comparison.

All the other types of comparisons work, but the file system one fails every single time.

This is a typical stack trace while attempting to compare file system (it fails also if the snapshots files are stored locally):

C:\Program Files\Microsoft Logo\Software Certification Toolkit\Windows System State Analyzer>SAnalyzer.exe compare "\\ServerName\c$\Users\Public\Documents\Pre install.bin" "\\ServerName\c$\Users\Public\Documents\Post install.bin" /fa CompareResult.html
Comparing snapshot..........
Snapshot compare complete
Generating Report....C:\Users\Public\Documents\CompareResult.html
Unhandled Exception: System.ArgumentOutOfRangeException: Index was out of range.
 Must be non-negative and less than the size of the collection.
Parameter name: index
   at System.ThrowHelper.ThrowArgumentOutOfRangeException()
   at System.Collections.Generic.List`1.get_Item(Int32 index)
   at Microsoft.Analyzer.Utility.DirectoryStatistics.CountDirectoryModified()
   at Microsoft.Analyzer.Utility.DirectoryStatistics.SetDirectory()
   at Microsoft.Analyzer.Utility.ReportsHelper.CreateXmlFile(ComparisonObject comparisonObject)
   at Microsoft.Analyzer.Utility.ReportsHelper.GenerateReport(String xslPath, String htmlPath, ComparisonObject comparisonObject)
   at Microsoft.Analyzer.SnapShotTool.CommandLineSupport.GenerateReport(String htmlPath, ComparisonObject comparisonObject)
   at Microsoft.Analyzer.SnapShotTool.CommandLineSupport.CompareSnapShot(String[] CommandLineInfo)
   at Microsoft.Analyzer.SnapShotTool.SingletonApp.ProcessCommandLine(String[] args)
   at Microsoft.Analyzer.SnapShotTool.Program.Main(String[] args)

Searching on the web, Markus' last post in this thread is probably describing the root of this issue:

https://social.msdn.microsoft.com/Forums/windowsserver/en-US/e9d3b3df-298b-4e6f-9058-6a3a94f86183/not-able-to-compare-using-windows-system-state-analyzer?forum=winserver2008appcompatabilityandcertification

I have tried to ask the Microsoft relevant team if they had plans to solve this issue, and release a new updated version of the tool, but their mailbox ([email protected]) doesn't work anymore.

Delivery to the following recipient failed permanently:

 [email protected]

Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the server for the recipient domain microsoft.com by microsoft-com.mail.protection.outlook.com. [23.103.156.42].

The error that the other server returned was: 550 5.4.1 [[email protected]]: Recipient address rejected: Access denied

The comparison tool works for the registry, the services, the drivers, but not for the file system.

Both from the GUI and the user interface.

I tried the comparison on a number of OS, e.g. from Windows 2012 R2 to Windows 7, and I have also tried the Microsoft XP compatibility mode, to not avail.

I have used this tool extensively in the past, to certify applications on Windows Server 2008 R2, and it used to work without a glitch.

Any suggested work around? Alternative suppliers?

Just logged in to a Windows host, I noticed an unexpected CPU usage. I quickly found out the processor was being hogged by the Windows firewall services. I enabled logging, and I started to see sheets after sheets of dropped TCP packets, with source and destination addresses as the IPv6 loopback address, but the source and destination ports slightly changing at every dropped packet.

Here is a snippet:

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
...
 2016-10-21 19:54:57 DROP TCP ::1 ::1 51330 51328 0 - 0 0 0 - - - SEND
 2016-10-21 19:54:57 DROP TCP ::1 ::1 51334 51332 0 - 0 0 0 - - - SEND 
 2016-10-21 19:54:57 DROP TCP ::1 ::1 51338 51336 0 - 0 0 0 - - - SEND 
 2016-10-21 19:54:57 DROP TCP ::1 ::1 51342 51340 0 - 0 0 0 - - - SEND 
 2016-10-21 19:54:57 DROP TCP ::1 ::1 51346 51344 0 - 0 0 0 - - - SEND
...

Even executing netstat -a -b, I was not able to identify the process who was sending those TCP packets. In this specific instance I luckily had the opportunity to be able to bounce the host, I bounced it, and the issue seems to have disappeared. Any idea of what may have caused the issue?

We have a Windows 7 machine (but in the near future we may use a Windows Server one) which we use for showing a screensaver on a big display. The host is in the company domain, we log to the machine with a domain account, and we set the screensaver timeout to 1 minute. If someone get console access, to login they must know the account password, as the screensaver is password protected.

Is it possible to configure the host to autologin and autostart the password protected screensaver at power on? If so, how to?

What we would like to achieve is for the screensaver to display straight away directly from power on the information on the display, without having the requirement to have to log in, and wait one minute for the screensaver to kick in, but maintaining the screensaver password protected.

I have one of my domains on the 2nd level domain .co.uk., registered with 123-Reg, a British DNs provider, and I get various services on that domain from Google Apps, by the note US company.

I would like to use a sub domain for services provided by another provider, specifically I would like to get PEC services from an Italian provider. PEC is an italian standard to digitally sign and certify emails, and basically I would like to use a pec.[mydomain].co.uk. 4th level domain (you may read RFC 6109 for further details about PEC, but I reckon that's not really necessary to answer my questions below, from my understanding on the DNS side it should really work as an usual mail server) for such PEC services.

From my understanding so far, I need to set up a MX record to point to the PEC provider (usually something like mx.pec.[provider].it.).

Currently my DNS settings look like this:

@   A       [x.y.w.z]
@   MX  1   ASPMX.L.GOOGLE.COM.
@   MX  5   ALT1.ASPMX.L.GOOGLE.COM.
@   MX  5   ALT2.ASPMX.L.GOOGLE.COM.
@   MX  10  ASPMX2.GOOGLEMAIL.COM.
@   MX  10  ASPMX3.GOOGLEMAIL.COM.
@   MX  10  ASPMX4.GOOGLEMAIL.COM.
@   MX  10  ASPMX5.GOOGLEMAIL.COM.
calendar    CNAME       ghs.google.com.
doc CNAME       ghs.google.com.
mail    CNAME       ghs.google.com.
my  CNAME       ghs.google.com.
www CNAME       ghs.google.com.

Am I right to think I should add at the very least a MX record as:

pec MX  10  MX.PEC.[provider].IT.

Also, I am right to think I'll have to add an A record, or a CNAME (whatever the Italian provider will ask me really, although I hope a CNAME will be enough), for pec as well?

Update 1

Just an update: I did purchase the PEC service from an Italian provider for a 4th level domain (on the .uk TLD, not the .it), they did let me apply for pec.[mydomain].co.uk., and then they did sell me a mail box on that domain (something like me@pec.[mydomain].co.uk.). They haven't yet sent me any special configuration info or request (I reckon I'll have to wait for the end of the process, they are currently "certifying" my domain, whatever they mean with certification in this context). I have decided to speed up things from my side, so I have already updated my domain DNS (serendipitously the provider I chose actually had their required mx record somewhere in the contract), so that my domain is already answering to mx lookups:

C:\>nslookup
Default Server:  [mydnsserver].co.uk
Address:  x.y.w.z

> set q=mx
> [mydomain].co.uk.
Server:  [mydnsserver].co.uk
Address:  x.y.w.z

Non-authoritative answer:
[mydomain].co.uk.     MX preference = 5, mail exchanger = alt1.aspmx.l.google.com
[mydomain].co.uk.     MX preference = 10, mail exchanger = aspmx4.googlemail.com
[mydomain].co.uk.     MX preference = 10, mail exchanger = aspmx5.googlemail.com
[mydomain].co.uk.     MX preference = 5, mail exchanger = alt2.aspmx.l.google.com
[mydomain].co.uk.     MX preference = 10, mail exchanger = aspmx2.googlemail.com
[mydomain].co.uk.     MX preference = 1, mail exchanger = aspmx.l.google.com
[mydomain].co.uk.     MX preference = 10, mail exchanger = aspmx3.googlemail.com

alt1.aspmx.l.google.com internet address = 173.194.70.27
aspmx4.googlemail.com   internet address = 173.194.78.27
aspmx5.googlemail.com   internet address = 74.125.130.27
alt2.aspmx.l.google.com internet address = 173.194.69.27
aspmx2.googlemail.com   internet address = 173.194.69.27
aspmx.l.google.com      internet address = 173.194.67.27
aspmx3.googlemail.com   internet address = 74.125.127.27
> pec.[mydomain].co.uk.
Server:  [mydnsserver].co.uk
Address:  x.y.w.z

Non-authoritative answer:
pec.[mydomain].co.uk. MX preference = 10, mail exchanger = mx.pec.[provider].it

mx.pec.[provider].it internet address = i.j.k.l
>

Update 2

At the moment, the answer is still a delivery failure (the reason is given in Italian, it stands for "The message was refused by the system. The address of the receiver is unknown, or it is not enabled to the reception of non certified mail"):

Delivery to the following recipient failed permanently:

    me@pec.[mydomain].co.uk

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 <me@[mydomain].co.uk>: Messaggio rifiutato dal sistema. Indirizzo destinatario sconosciuto o non abilitato alla ricezione di posta non certificata. (state 14).

But I reckon at the moment I have just to wait.

Update 3

I got the PEC mailbox settings from the provider, and everything works fine, the message were not delivered because by default PEC providers do not accept mails from non PEC mailbox, I had to fiddle with the settings to allow those in, and even after they are received in a funny way (they are marked as an "anomaly"), but all this is PEC specific, it does look like from a DNS point of view that all is required is just a MX record.