I have virtualized Microsoft Office 2010 Professional Plus with Service Pack 2 using VMware ThinApp v5.1.x, and it is working flawlessly so far. I have also opted to create cmd.exe at the time of building the package which can read the virtual environment. Now what my concern is, it doesn't matter if I activate it, that is for 180 days, using mini-KMS activator or Microsoft Toolkit before building the package, or I simply choose to keep it running in trial/grace period. When I activate the virtualized Microsoft Office using either mini-KMS activator or Microsoft Tool Kit or even try to check the number of days left before next activation could take place by making use of any of the above tools or by executing the below command using the virtualised cmd.exe cscript "%ProgramFiles%\Microsoft Office\Office14\ospp.vbs" /dstatus Every time I get the same error stating "The Software Protection Platform service is not installed" Is there any solution to that, or instructions to launch the Software Protection Platform service manually on the host machine on demand.
i can say one thing, i'd definitely be interested in "testing" your virtual build out if you want to share a link (PM)
It's Microsoft Office 2010 and Adobe Acrobat Pro XI virtualized together, the .dat file itself is 5.5 GiB after compression; it's a waste of resources on a build such as this which has issues. But I will post my build here at MDL once this issue is addressed, because this is the only issue I have confronted so far that persists, so that others can download and carry out tests and post the issues which then we all can attempt to solve together.
You can use the SC command (Service Control - Create, Start, Stop, Query or Delete any Windows SERVICE) to check a service. Through the command prompt enabled in the Office package: Code: C:\Windows>sc qc sppsvc [SC] QueryServiceConfig SUCCESS SERVICE_NAME: sppsvc TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : C:\Windows\system32\sppsvc.exe LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : Software Protection DEPENDENCIES : RpcSs SERVICE_START_NAME : NT AUTHORITY\NetworkService C:\Windows>sc qc osppsvc [SC] QueryServiceConfig SUCCESS SERVICE_NAME: osppsvc TYPE : 10 WIN32_OWN_PROCESS START_TYPE : 3 DEMAND_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : "C:\Program Files\Common Files\Microsoft Shared\OfficeSoftwareProtectionPlatform\OSPPSVC.EXE" LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : Office Software Protection Platform DEPENDENCIES : RpcSs SERVICE_START_NAME : NT AUTHORITY\NetworkService C:\Windows> Both sppsvc and osppscv are running as services under NT AUTHORITY\NetworkService. The issue is something else.
For reasons unknown, the KMS activator looks for the service on the host machine rather than finding it running already in the virtual environment. Where in fact, if the KMS tools execute cscript "%ProgramFiles%\Microsoft Office\Office14\ospp.vbs" /OPTION .. command to activate or even check the activation status, then possibly either cscript or ospp.vbs is the one looking for the service on the host machine rather than finding it running already in the virtual environment. I can tell this because I ran a KMS Activator ThinApp, packaged on a virtual machine (X) along with the other Office ThinApps, on a host machine (Y) with Office preinstalled, and surprisingly it gave me the activation status of the Office installed on the host machine (Y) instead. ANY CLUES? ANYONE?
You might be on to something. It could be a missing/malformed virtual registry entry which the package can't find, so it goes looking for it on the host file system where it may not exist anymore. You can create an entry point for regedit along with cmd and compare osppsvc registry entries between the build machine and the package.
Enlighten me. I always make entry points for regedit and cmd, but can you suggest a better way to compare strings pertaining only to OSPPSVC instead of the entire registry.
You know sometimes it reminds me of response from the Hologram of Dr Lanning from the movie I, Robot Hologram: I'm sorry, my responses are limited. You must ask the right questions. Hologram: That, Detective, is the "right question." May be the problem is something else, other than the reply we are getting.
I think it is something else and it has little or nothing to do with the virtual registry. The error message is from ospp.vbs. It's declared early in the script: Code: CONST MSG_OSPPSVC_NOINSTALL = "Error: The Software Protection Platform service is not installed." and it's used like this: Code: Set colListOfServices = objWMI.ExecQuery _ ("Select * from Win32_Service ") For Each objService in colListOfServices If objService.Name = "osppsvc" Then installed = True If LCASE(objService.State) = "running" Then running = True End If Exit For End If Next If installed <> True Then globalPopFailure MSG_OSPPSVC_NOINSTALL,True End If Looks like a WMI query of the Win32 Services running, and even though both osppsvc and ospp.vbs are packaged, and osppsvc is running in the package, the result will reflect the state of osppsvc on the host. I guess the trick would be to get ospp.vbs working in a package somehow, or, if even possible, alter the ospp.vbs script to work locally in the package. Easier said than done. (like my last bit of advice)