Topology file management #883
-
Hi everyone, I'm trying to understand how those Service Models are managed : With #878 issue fix, it shouldn't be a problem anymore but when I execute And this error occurred : Whereas I don't have Retail elements anymore in IIS : Thank you ! :) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
Hey, thanks for reporting. Can you share more information about the environment where this is done? If it is a local VHD environment, what vhd image version was used to set it up? If it is a cloud hosted environment, when was it deployed and with what version? Were updates installed on the environment before? From what I see in the posted logs, the change from #878 is unrelated. Otherwise, there would have been messages in the log about using a fallback. This seems to be an issue where the Microsoft standard update logic does not correctly identify the installed components.
As a workaround, you can edit the topology file to remove the retail components. Then run |
Beta Was this translation helpful? Give feedback.
-
Hi @FH-Inway ! Thank you for your quick answer 😉 Sorry for the lack of informations, it's on a VHD, yes. It was on the 10.0.41 VHD version. On one side, during a 10.0.42 SPD, I faced this issue but you were saying on Yammer that it was related to another problem : https://www.yammer.com/dynamicsaxfeedbackprograms/#/Threads/show?threadId=3172972962234368 My second test was on 10.0.41 VHD with 10.0.43 SDP, I believed that it was fix for this 10.0.43 update. Here is my logs folder on my 10.0.43 updated VHD : Here is the AXUpdateInstaller.exe list : Maybe I didn't understand well but I thought Retail components have been removed since 10.0.41 VHD. I don't want to manage a TopologyFile because I just need to ignore Retail elements but, yes, it's working (maybe I didn't update enough components). Here is the TopologyFile I used for 10.0.43 SDP :
I'm a bit confused. I'll try to delete files in Thank @FH-Inway ! |
Beta Was this translation helpful? Give feedback.
-
Glad it worked out for you. Yeah, ever since the 10.0.39 VHD, updates have gotten messy. You are right, starting with the 10.0.41 VHD, the Retail components have been removed. I'm not sure why they are discovered on your environment. One guess is that I think there were several versions of the 10.0.41 VHD (but my memory may be wrong here). Maybe you got an earlier version where the components were not removed yet? The other guess I have is that the failing 10.0.42 upgrade may have somehow (maybe with an older d365fo.tools version that did not have the fixed fallback?) installed the Retail components insofar as to make them discoverable by the AXUpdateInstaller.exe list logic? Not sure how that would work. Not directly related to your issue, but since it got me thinking, here is a timeline as I understand it regarding the update issues in general:
@Splaxi fyi |
Beta Was this translation helpful? Give feedback.
-
Since no feedback way provided by Microsoft on the 10.0.43 VHD issue with the missing AOSService component and the next update 10.0.44 will soon be relased, I created #887 to address this issue. |
Beta Was this translation helpful? Give feedback.
Hey, thanks for reporting. Can you share more information about the environment where this is done? If it is a local VHD environment, what vhd image version was used to set it up? If it is a cloud hosted environment, when was it deployed and with what version? Were updates installed on the environment before?
From what I see in the posted logs, the change from #878 is unrelated. Otherwise, there would have been messages in the log about using a fallback. This seems to be an issue where the Microsoft standard update logic does not correctly identify the installed components.
[Microsoft.Dynamics.AX.AXInstallationInfo.AXInstallationInfo]::GetInstalledServiceModel()
determines the installed c…