When you create VM from a captured image, the drive letters for data disks may not preserved. For example if you have system database files on E: drive, it may get swapped to H: drive. If this is the case, SQL Server can’t find system database files and will not start. If the driver letter mismatch occurs on user database files, then the user databases will not recover. After VM is created, you just need to go to disk management to change the drive letters to match your original configuration.
Unable to log onto SQL Server using Windows account
This issue is a bit more complex. When you use sysprep to generalize the image, the SID for the machine is deleted and Windows users you created will be deleted as well. If you rely on Windows login to access SQL Server, you won’t be able to log in. Let’s assume that you create your original VM that contains SQL Server using administrator called azureadmin. azureadmin will be added as sysadmin as part of VM creation. After you use sysprep, the user will be deleted. When you create a new VM out of that image, you can specify the same user name and password. But that will be a totally new user. As a result, you can not log in using the ‘same’ Windows user anymore. Let’s summarize what you need to do in order to solve the issue. The key is to add a few steps to prepare yourself before capturing the VM.
Prepare your SQL VM before image capture/sysprep
Configure SQL Server to accept SQL authentication
Create a SQL Server login as sysadmin and remember the password.
Make sure no databases or objects are owned by the Windows login. Instead, make sure all objects and databases are owned by sa or an SQL login.
After VM creation (from the captured image)
Log onto SQL Server using the SQL Server login you created in the step 1 above.
Delete the original Windows user and add the new windows user back. Note that even you use same name, the SID will be different and it can’t be used to log onto SQL Server.